Kernel Traffic #196 For 2002/12/16

There were 385 different contributors. 208 posted more than once. 161 posted last week too.

Teraz, gdy wydano 2.4.20, chciałbym popracować z Wami nad wprowadzeniem kodu ACPI do 2.4.21-pre tak szybko, jak to tylko możliwe. Ten kod cały czas jest testowany przez więcej niż 500 osób na liście dyskusyjnej acpi-devel i był włączany do 2.5.x wraz ze wszystkimi poprawkami.

Sądzę, że wykonaliśmy wystarczającą pracę, żeby zminimalizować wszystkie problemy, a wczesne włączenie do serii łatek -pre da nam czas na reakcję na wszystkie ewentualnie zgłoszone problemy.

Możecie spojrzeć pod adres: (przepraszam za długi URL)

http://linux-acpi.bkbits.net:8080/linux-2.4-acpi/user=agrover/ChangeSet@-6M? nav=!-|index.html|stats|!+|index.html

Oprócz bardzo wczesnych zbiorów zmian, całość zawiera poprawki przyrostowe, które robiliśmy w ostatnim roku. Policzyłem 69 istotnych zbiorów zmian.

url dla bk: http://linux-acpi.bkbits.net/linux-2.4-acpi

Arjan van de Ven oprotestował tę łatkę i poprosił Marcelo Tosattiego żeby jej nie włączał. Wyjaśnił: "Ta łatka usuwa z jądra istniejącą, małą, działającą i utrzymywaną funkcjonalność i ,,zastępuje'' ją czymś, co nie jest akceptowane, dużo większe, i ma mniej czytelny kod," a potem dodał: "To nie tylko jest niegrzeczne ze strony ludzi od ACPI, że chcą usunąć ,,konkurencyjną'' funkcjonalność, takie działanie zepsuje wszystkie rodzaje istniejących ustawień; teraz trzeba będzie zmienić sposób konfiguracji systemu. Dodam jeszcze, że to nie jest potrzebne, istniejący kod może współistnieć z tym, co proponuje Andrew, dowiodło tego jądro United Linux."

Andrew odpowiedział, że nowy kod po prostu unifikuje kod ACPI w 2.4 z kodem, który od dłuższego czasu jest w 2.5. Zapytał: "Czy Ty tak troszczysz się o kod, czy o opcje linii poleceń? Mogliśmy oczywiście zatrzymać tę samą opcję linii poleceń ,,acpismp=force'', jeśli w tym leży problem, ale zawsze wydawało mi się, że to trochę dziwna nazwa opcji." Alan Cox odparł: "dziwna, czy też nie - zmienianie jej w 2.4 jest złym pomysłem - zachowanie jej jako opcji wraz z opcjami z 2.5 jest bezpieczniejsze. 2.4 powinno wciąż działać po aktualizacjach tak, jak ludzie tego oczekują - konserwatyzm jest tu kluczem. Wydaje mi się, że o to chodzi Arjanowi." Arjan także odpowiedział Andrew, pisząc: "moja największa troska to to, że psujesz istniejące ustawienia albo przynajmniej zmieniasz je bardziej niż tego wymagają. Potrzeba usuwania istniejącego, działającego (i chudego) kodu jest ZEROWA, nawet jeśli Twój kod potrafi to samo. Oznacza to, że ludzie będą nagle musieli zmienić wszystkie rodzaje opcji konfiguracyjnych, kod jest inny, więc będzie działał trochę inaczej... unifikacja z 2.5 jest przyjemna, ale nie ma powodu jej dokononywać w tym przypadku, gdy obie implementacje mogą łatwo koegzystować."

Andrew zapytał, czy najlepszym rozwiązaniem byłoby użycie łatki z jądra United Linux i przyrostowe dodawanie innych pożądanych zmian. Arjan jednak odpowiedział, że nie, bo to co jest potrzebne to zastąpienie kodu, który usuwa pierwotna łatka Andrew. Nie ma potrzeby porzucać całej łatki.

Po pogadaniu z Marcelo wydaje się, że chciałby on powstrzymać umieszczanie tego w 2.4.21, bo priortytetowe są zmiany w IDE, a dwie duże zmiany na raz mogą okazać się przesadą dla stabilnej wersji jądra.

Szczerze mówiąc, to po prostu boję się, że 2.4.22 jeszcze hen przed nami.

Być może jakimś sposobem na zaspokojenie wątpliwości Marcelo co do stabilności i postulatów Arjana o zatrzymaniu acpitable.[ch] jest przygotowanie przez mnie łatki, o której jestem *pewien*, że nie dotyka niczego oprócz ACPI -- to znaczy zawiera tylko te zmiany, które zostały zrobione w drivers/acpi jako startu, a potem przyrostowo przesyłać poprawki wywodzące się z UL lub jakieś inne.

Zapytał ludzi, czy to wydaje się właściwym podejściem do sprawy, a Pavel Machek odpowiedział, że tak: "To oczywiście lepsze niż zupełny brak aktualizacji ACPI." Jednakże Hanno Boeck był bardzo zawiedziony tym opóźnieniem. Napisał: "Moim zdaniem łatka ACPI jest w tej chwili najbardziej potrzebną łatką na jądro. Dla wielu użytkowników laptopów, którzy nie wiedzą o tej łatce, Linux jest prawie nieużywalny. Poza tym wiem już o przynajmniej dwóch biurkowych pecetach, które nie mają żadnego zarządzania zasilaniem bez acpi-patch. Andrew, mam nadzieję, że znajdziesz jakiś sposób na to, żeby ludzie od jądra zaakceptowali tę łatkę najszybciej jak to jest możliwe." Arjan odparł, że ponieważ 2.4 nie ma właściwie możliwości zawieszania/odwieszania, to łatki te nie są znowu aż tak pożądane. Matthew Wilcox i Alan zwrócili jednak uwagę, że bez nich wiele systemów nawet nie wystartuje. Marcelo zapytał, których systemów dotyczy ten problem, a Alan napisał: "Nowe compaqi, istniejące xmeta, nowe HP nie wystartują bez IDE -ac i obejść dla ATi lub poprawek ALi IDE. (Użytkownicy powinni narazie unikać rzeczy ati igp - nie ma obsługi X, nie ma obsługi rutingu pci, większość jąder nie będzie na tym działać, nie ma dokumentacji." Matthew dodał też: "komputery z ia64 hp oparte o zx1 (to mnie osobiście intresuje..) i sądzę, że niektóre laptopy wymagają uaktualnionego ACPI żeby wstawać. Co więcej, czy nie istnieją takie maszynki SMP x86 z popsutymi tablicami bios, które także nie wystartują bez ACPI?" Jeff Garzik dodał: "Jest kilka klas komputerów, które wymagają ACPI... istotne pytanie brzmi, czy te maszyny potrzebują pełnego ACPI, czy wystarczy im acpitable.c..."

Arjan zwrócił uwagę, że przynajmniej maszynki HP oparte na zx1 z ia-64 wymagają także kilku innych łatek, żeby mogły wystartować, ale Bjorn Helgaas odparł: "Oprócz ACPI, łatki nie będące łatkami ia64, które są wymagane do wystartowania zx1 powinny być względnie małe: pewne zmiany w IRQ, obsługa nieciągłej pamięci w memmap_init itp." Dodał: " Posiadanie nowszego ACPI w 2.4.x (obecnie jest to 20011018!) ułatwiłoby wiele działań dla ia64."

Dostępna jest nowa łatka. Jest to łatka na 2.5.50. Można ją pobrać z:

http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

Dobrej zabawy!!!!

Przeniesione sterowniki to: (Dajcie im szansę)

ATI Mach 64
ATI 128
VESA
VGA16
HGA
NIVIDA
NEOMAGIC

DUŻE zmiany to:

Oddzielenie kodu konsoli od sterowników fbdev.
Pełna modularność systemu konsoli framebuffera. Tak, właśnie tak. Są moduły. Świetne do testowania.

To co poniżej to wyniki nowych zmian, które przetestowałem.

Z moim laptoptem VIA i kartą neomagic mogłem to skompilować z vgacon i bez fbcon. Potem zrobiłem insmod neofb i wymaganą akcelerację (cfb*.c). Załadowało się i NIE zmieniło stanu sprzętu. W tym momencie mogłem uruchamiać aplikacje fbdev, włączając w to serwer X używając bezpośrednio /dev/fb. Przy otwarciu /dev/fb0 zmienił się stan sprzętu obsługującego grafikę. Teoretycznie mogłem wyjść z X i z powrotem dostać vgacon. Żeby to zrobić trzeba przenieść sprzęt z powrotem do trybu tekstu vga z funkcji fb_release. To można zrobić, ale jeszcze nie próbowałem.

W drugim eksperymencie mogłem zrobić insmod fontów i fbcon.o. Wtedy przeszedłem z vgacon na fbcon. W teorii mógłbym znowu zawołać funkcję zwalniającą i przejść z powrotem do trybu tekstowego. Wszystko, czego potrzeba w tym celu to kod zależny od sprzętu.

Rzeczy do zrobienia:

Parę pluskw w fbcon do wytłuczenia.
Obsługa zmiany rozdzielczości przez wartstwę konsoli w fbcon.
Przeniesienie kodu logo z fbcon.c do fbmem.c. Przy czystym fbdev potrzeba czegoś, co pozwoli mieć świadomość, że działa.
Obracanie programowe.

Christoph Hellwig zapytał: "Czy jest jakaś szansa na to, że zsynchronizujesz się znowu z drzewem Linusa? Fb w głównym jądrze jest dość zwalone." A James odpowiedział: " Sądzę, że przyszedł już na to czas. Zdarzyło się wiele poprawek :-) Ostateczna wersja api dla sterowników niskiego poziomu jest już gotowa. Wszystkie dalsze zmiany będą w fbmem.c i fbcon. Pozbierałem po prostu do kupy ostatnie prace. "

Poniżej podstawowa część początków warstwy zgodności wołań systemowych (ang. comatibility syscall layer). Sądzę, ze jest na tyle podstawowa, że w każdej architekturze da się zdefiniować co oznacza zgodność.

Żeby tego używać, dla architektury trzeba stworzyć asm/compat.h i dostarczyć tam definicji typów dla (aktualnie) compat_time_t, compat_suseconds_t, struct compat_timespec.

Mam nadzieję, że to jest właśnie to, co mieliście na myśli - w przeciwnym wypadku marsz z powrotem do tablicy.

Będę teraz przesyłał łatki specyficzne dla architektur, które już zrobiłem, ale jeszcze nie testowałem.

Spotkało się to z ogólnym aplauzem, podbało się też Linusowi Torvaldsowi, choć miał kilka kosmetycznych zastrzeżeń. W trakcie dyskusji nad implementacją, Linus uczynił następującą, związaną z tematem uwagę:

Alpha (i najwyraźniej sparc) po prostu _w_ogóle_ nie zachowują na stosie rejestrów wymaganych przez obsługę sygnałów. Jest zbyt wiele rejestrów do zapamiętania przy każdym wołaniu, a 99% wołań systemowych nigdy ich nie potrzebuje.

Powrót z wołania systemowego, który sprawdza czy nie ma sygnałów zawsze będzie musiał trzymać specjalną ramkę na stosie. To samo będą robiły specjalne wołania związane z sygnałami (sigsuspend() i koledzy). To wszystko nie jest tylko zależne od architektury, jest bezpośrednio zakodowane w asemblerze dla architektur. Sprawdźcie 'do_switch_stack()' dla procesorów alpha.

W każdym razie, jeśli zastanawialiście się dlaczego Linux bije na głowę wszystkie inne Uniksy pod względem narzutu na wołanie systemowe, to teraz już wiecie. I tak, to jest ważne.

Shane Helms spytał, czy niskopoziomowy rozwój jądra osiągnął już swój koniec i czy w związku z tym w Linuksie będzie możliwy rozwój tylko peryferyjnych obszarów, takich jak optymalizacja, drobne udogodnienia, bezpieczeństwo i tego typu rzeczy. Na linux-kernel śmiano się z tego, a ludzie zapewniali Shane'a, że jest jeszcze sporo rzeczy do zrobienia. Pomiędzy tymi zapewnieniami Shane podjął dyskusję: "jeśli sugerujecie, że możemy zacząć jeszcze raz od samego początku i dostać coś lepszego niż unix (który miał przez długi czas otwarty kod i był też testowany i rozwijany przez wielu ludzi), to ja _BARDZO_ wątpię i się z tym nie zgadzam. Oczywiście, o ile główni deweloperzy jądra nie *przyznają*, że popełnili jakieś błędne decyzje na samym początku projektowania (w głównej sekcji czy czymś takim), z którymi teraz, cały czas się użerają, a błędy przechodzą pomiędzy kolejnymi wersjami jądra bez możliwości ich usunięcia bez rozpoczynania wszystkiego od początku." Joseph D. Wagner odpowiedział:

Tak i nie.

Deweloperzy Uniksa (i Linuksa) są zdecydowanie zbyt zaangażowani w trzymanie się 30-letniego, przestarzałego standardu POSIX, który tworzy niezliczone problemy, gdy próbuje się wdrożyć nowe rzeczy. Na przykład to standard POSIX jest przyczyną posiadania schematu uprawnień do plików trzy-na-trzy (trzech użytkowników: właściciel, grupa, każdy; trzy uprawnienia: odczyt, zapis, wykonywanie) zamist List Kontroli Dostępu (ACL).

Nie.

Tylko głupi ludzie myślą, że mogą wyrzucać stare, sprawdzone pomysły. Tak się dzieje często w środowiskach akademickich, że gdy znajdzie się problem, który trzeba rozwiązać, przeprojektowuje się cały system dookoła poprawki.

W ten sposób dostajemy takie śmieci, jak mikrojądra. Mają ,,plan'' i to jest _najgorsza_ rzecz, jaką można mieć przy projektowaniu oprograwmowania. Naprawiasz jakiś wydumany problem, i w końcu rzeczywiście naprawiasz ten problem, ale w międzyczasie generujesz całe mnóstwo nowych problemów -- zazwyczaj takich, które były rozwiązane w oryginalnym podejściu.

Podejście UNIKSOWE/Linuksowe jest bardzo pragmatyczne -- pozostawia rzeczy dobrze działające samym sobie. Nie ma sensu w ponownym wymyślaniu całego systemu tylko dlatego, że są gdzieś małe problemy.

Shane zapytał: "skoro nie zmieniamy tak wiele w samym rdzeniu jądra i rozwój skupia się głównie na dodawaniu dodatkowego kodu i warstw dla bezpieczeństwa, rozszerzeń funkcjonalności i obsługi nowego sprzętu itp. Czy to nie spowalnia jądra? Czy kod wykonujący to wszystkie jest taki sam??" A Linus odrzekł:

Och, niektóre rzeczy w istocie zostają spowolnione. Próbujemy unikać psucia krytycznych ścieżek, a na przykład obsługa nowego sprzętu (który wydaje się zajmować znaczną część rozwoju jądra, nawet jeśli nie jest tak sexy, jak dodawanie nowej funkcjonalności) nie ma w ogóle negatywnego wpływu na resztę jądra.

To co na przykład ujrzymy w 2.6.x, to to, że wiele mikrotestów wykaże lekkie spowolnienia (fork() i execve() uległy widocznemu spowolnieniu z powodu łatek rmap), ale dzięki temu uzyskaliśmy znacznie lepsze zachowanie w sytuacjach brzegowych i znacznie lepszą skalowalność.

I wiele rzeczy _może_ być zrobionych bez wyrzucania starych projektów. Poprawki w implementacji są możliwe bez prób wykonania czegoś zupełnie nowego. Tak się na przykład dzieje z dcache -- zachowujemy stare, nudne i standardowe podejście uniksowych systemów plików, jednocześnie wykorzystując różne nowe mechanizmy wewnętrznego cache'owania, znacznie poprawiając wydajność.

Niewylewanie dziecka z kąpielą nie oznacza, że nie możesz poprawić systemu. Kłócę się jedynie z głupimi ludźmi, którzy sądzą, że potrzeba rewolucji, aby coś poprawić -- większość rzeczywistych ulepszeń jest ewolucyjna.

W chwili obecnej nasze jedyne API DMA jest bardzo ukierunkowane na PCI (tworzenie dowolnej szyny nie-pci z kontrolerem DMA tworzy fikcyjne urządzenie PCI, aby na nim operować).

Skoro teraz mamy ogólny model urządzeń, powinno być równie możliwe, aby zapisać całe API przy pomocy ogólnych urządzeń zamiast pci_devs.

Załączona łatka właśnie to robi (dla x86 -- choć mam i działający kod dla parisc, gdzie właściwie testowałem to całe DMA).

API jest w zasadzie identyczne jak to z PCI DMA z jednym istotnym wyjątkiem dotyczącym ciągłości pamięci:

API PCI ma pci_alloc_consistent, która alokuje jedynie ciągłą pamięć i kończy się porażką, gdy nie ma dostępnego takiego kawałka pamięci, co prowadzi to tego, że obsługę nieciągłej pamięci trzeba pisać w samym sterowniku, tak aby wykrywać takie sytuacje i implementować strategię w przypadku niepowodzenia.

Nowe API DMA pozwala sterownikowi na ogłoszenie swojego poziomu zgodności ciągłości pamieci do pci_alloc_consistent. Są w zasadzie dwa poziomy:

Pracuję jedynie z ciągłą pamięcią, jeśli nie mogę jej dostać, to porażka, lub
Mogę pracować z nieciągłą pamięcią, spróbuj dostać najpierw ciągły kawałek, ale jeśli się nie uda to pobierz nieciągły kawałek.

Pomysł polega na tym, że typ pamięci może być zapisany w dma_addr_t, które może użyć kolejnych operacji synchronizacji pamięci do ustalenia czy funkcja wback/invalidate powinna być pusta, czy nie.

Użycie tego schematu pozwoliło mi na usunięcie całej obsługi nieciągłej pamięci z moich sterowników.

Naprawdę chciałbym takie zmiany, jak Twoje, zobaczyć szybko zintegrowane z oficjalnym jądrem, aby zakończyć rozprzestrzenianie się udawanych urządzeń PCI (włączając w to konwencję pcidev==NULL) i inne skrzywienia narosłe wokół tego. Taka zmiana pozwoliłaby również na konsolidację różnych alokacji pamięci i różnej, często nieprawidłowej obsługi błędów z setek sterowników do jedynie kilku miejsc.

Jak wiesz, wysłałem podobną łatkę, która tworzyła nowe pole w strukturze but_type, jak to zasugerował Miles Bader, ale jedynie dla {alloc,free}_consistent. Jeśli wariacja dla szyny może zostać zawężona do mniejszych części tych procedur lub wyeliminowana, to jestem cały za opuszczeniem tych ekstra przekierowań i zamierzam poprzeć Twoje podejście. Będzie ciekawym doświadczeniem zobaczyć, czy Twój model pozwala na większość mapowań procedur DMA sbus_ i pci_ na sparcu. Podejrzewam, że będziesz musiał zaadoptowac jakąś konwencję, taką, że device->parent->driver_private będzie miało wspólne znaczenie dla urządzeń pci i sbus na tej platformie.

Jeff Garzik również zaoferował swoją pomoc mówiąc: "Cieszę się, że James się tym zajął. Pomoże to oczyścić wiele założeń i paskudztw z sytuacji brzegowych..."

Spore grono deweloperów przez jakiś czas dyskutowało techniczne szczegóły: nazwenictwo, architekturę itp. W pewnym momencie Russell King przedstawił kilka technicznych zastrzeżeń i zauważył, że implementacja byłaby tak brzydka, że "raczej bym pozostawił istniejące API pci_* niż zmuszał do tworzenia tego śmiecia." James na do odparł:

Może lepiej to objaśnię: nie mam zamiaru usunąć API pci_*, ani jakoś zasadniczo sie od tego odciąć. Nie planuję nawet zmuszać do tego jakiejkolwiek architektury, która nie chce tego zrobić. Myślę jedynie o umieszczeniu czegoś takiego w implementacjach asm-generic:

dma_*(struct device *dev, ...) {
        BUG_ON(dev->bus != &pci_bus_type)
        pci_*(to_pci_device(dev), ..)
}

Chodzi o to, aby nie zmuszać do masowych zmian w sposobie pisania sterowników, tylko o udostępnienie API opartego na ogólnych urządzeniach dla tych, którzy tego potrzebują. Jest jedynie kilka sterowników, które potrzebuja alokować nieistniejące urządzenia PCI, a to API jest skierowane głównie jako pomoc dla nich. Sterowniki, które operują jedynie na prawdziwych urządzeniach PCI nie wymagają żadnego zachodu.

Nowy kod interpretera ACPI AML (to znaczy kod w katalogach drivers/acpi, ale nie źródła bezpośrednio w drivers/acpi) zostały opublikowane przez nas (Intela) na GPL. Zostało to także oddzielnie opublikowane na luźniejszej licencji, tak, żeby inni producenci systemów operacyjnych mogli z tego skorzystać.

Jedną z konsekwencji tego czynu jest to, że nie mogliśmy bezpośrednio czerpać korzyści z łatek innych twórców Linuksa, dlatego, że łatki, które były publikowane na GPL muszą pozostawać na GPL, a zatem nie mogliśmy ich brać i cały czas utrzymywać naszego kodu na licencji innej niż GPL. (Musieliśmy znaleźć problem, który był poprawiany przez daną łatkę, a potem własnoręcznie wykonywać poprawkę.)

To spowolniało rozwój i zmniejszało uczestnictwo społeczności w procesie rozwoju.

Żeby rozwiązać ten problem, rozważamy opublikowanie linuksowej wersji interpretera na podwójnej licencji. To pozwoliłoby na bezpośrednie włączanie zmian. Wszystkie przesyłane łatki na główny kod ACPI byłby w ten sposób możliwe do użycia przez nas w kontekście nie GPL. To już zostało zrobione w innych miejscach jądra, na przykład w kodzie PCMCIA.

Christophowi Hellwigowi się to spodobało i zaproponował: "Użyjcie proszę znanej licencji dla drugiej opcji, na przykład MPL. " Alan Cox także nie miał zastrzeżeń do propozycji Andrew, co wyraził pisząc:

Sądzę, że to wyjątkowo dobry pomysł. Nie miałbym żadnych obiekcji, gdybym miał ofiarować poprawki do projektu, który byłby prowadzony na takich warunkach. I jeśli zrobię coś wielkiego i bardzo super z ACPI, to ciągle mogę to opublikować tylko na GPL, a wy ciągle możecie to zignorować 8)

Jest pewna tradycja ofiarowania łatek na licencji projektu, którego one dotyczą (a ACPI jest oczywiście wystarczająco duże, żeby było 'projektem', a nie po prostu łatką)

Mnie to odpowiada.

Skoro pcmcia już ustanowiła przykład taką licencją, to sądzę, że to świetny model do naśladowania.

Powtarzam także komentarz o wybraniu znanej już licencji, takiej jak MPL lub BSD (itp), żeby prawnicy nie mieli dodatkowej pracy ;-)

Greg KH także nie miał zastrzeżeń do propozycji Andrew. W innym miejscu Adrian Bunk odpowiedział na początkową propozycję Andrew:

dwa komentarze na temat prawa autora do wolnego wyboru licencji, pod którą chce udostępnić swoją łatkę:

Jeśli przesyłający łatkę chce umożliwić wam używanie jego łatki na zasadach obydwu licencji, to może wam to już umożliwić.

Nie możecie zakazać ludziom przesyłania łatek, które są tylko na GPL, zatem jeśli ktoś nie chce, żeby jego łatka była na luźniejszej licencji, to nie możecie go zmusić do opublikowania jej na luźniejszej licencji.

To prawda, ale z drugiej strony mieliśmy już te podwójne licencji (wspomniano o PCMCIA, ale dotyczyło to także reiserfs i pewnej liczby sterowników takich jak aic7xxx) i nie wydaje mi się, żebyśmy _kiedykolwiek_ dostali łatkę, w której nie zezwolono na podwójne licencjonowanie.

W rzeczywistości wydaje mi się, że nigdy nie włączyłbym łatki, która przesłana by była przez osobę próbującą ograniczyć kod będący na podwójnej licencji do pojedynczej (to może się przydarzyć jakiemuś nieutrzymywanego kodu, gdzie oryginalne źródło podwójnej licencji jest nieaktualne, ale jeśli ktoś spróbuje przysłać mi łatkę ACPI, o której powie ,,to jest tylko na GPL'', to ja po prostu tego nie wezmę).

Podejrzewam, że takie samo zachowanie, czyli ,,odrzucanie łatek, które ograniczają licencje'' będzie wspólne dla większości opiekunów jądra. Przynajmniej dla mnie wybór licencji przez _początkowego_ autora jest o niebo ważniejszy niż techniczna poprawność limitowania tego wyboru do jednej licencji.

Zatem tak, kod na podwójnej licencji może stać się kodem tylko na GPL, ale nie w _moim_ drzewie.

Ktoś może się odłączyć i przygotować swoje własne dodatki opublikowane tylko na GPL i całkiem uczciwie powiem, że ignorowanie intecji pierwotnego autora uznałbym za moralnie obraźliwe, że nie wziąłbym tego kodu nawet jeśli byłaby to poprawka (co prawda przekonałem się, że ludzie, którzy są ograniczeni w poglądach co do licencji, są zwykle ograniczeni w innych rzeczach, więc wątpię, czy _byłaby_ to istotna poprawka).

H. Peter Anvin zauważył: "To dobrze. Chciałbym utrzymać klibc pod licencjami BSD/GPL, bo niektórzy ludzie (na przykład Al Viro) miał pewne wątpliwości w kwestii publikacji niedynamicznej biblioteki z przestrzeni użytkownika na GPL lub LGPL, a ja w sumie zgadzam się z tymi obawami. Obecny tarball z klibc nie jest zupełnie ,,nienapiętnowany'', bo w paru miejscach zawiera ,,poprawione''/zmodyfikowane nagłówki z jądra, ale mam nadzieję przenieść te zmiany z powrotem do nagłówków jądra, gdy zostanie już zrobione włączenie."

Ta łatka aktualizuje UML do 2.5.50. Jeśli chodzi o samego UML, to nic się nie zmieniło w porównaniu do 2.5.49.

UWAGA: Z tą wersją jestem w stanie wygenerować powtarzalne uszkodzenie systemu plików. Jednak nie wygląda to na moją winę, więc robię kolejne wydanie. Nie zauważyłem żadnych takich narzekań (ani poporawek) o 2.5.50 na lkml, ale być może nie zwracałem dostatecznie na to uwagi. Jeśli jest poprawka, zaaplikujcie. Jeśli nie, używajcie tej wersji na systemie plików, który może się skaszanić.

Łatka UML do 2.5.50 jest dostępna pod adresem
http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.50-1.bz2

Inne serwery lustrzane UML i inne pliki do ściągnięcia znajdziecie pod adresem
http://user-mode-linux.sourceforge.net/dl-sf.html

Inne ciekawe odnośniki:

Strona domowa projektu UML : http://user-mode-linux.sourceforge.net
Serwis społeczności UML : http://usermodelinux.org

Nathaniel Russell ogłosił: "Niniejsza łata dodaje obsługę karty AGP Via 8633." Dodał: "Przygotowana dla jądra 2.4.20; prawdopodobnie działa również z serią 2.5.x."

Nathaniel Russell ogłosił: "Ta łata dodaje obsługę zintegrowanej karty dźwiękowej Via8233. Nakłada się czysto na jądro 2.4.20. Zmienia wyłącznie plik drivers/sound/via82cxxx_audio.c. Proszę o nałożenie na aktualne jądro 2.4.x" Ale Jeff Garzik odpowiedział: "Niestety, działa tylko sporadycznie i tylko dla niektórych płyt głównych. Jest powód, dla którego usunąłem ten identyfikator pci ze sterownika po tym, jak go głupio dodałem. :)" Zasugerował w późniejszym liście: "Dave Jones naprawdę ładnie oczyścił agpgart w 2.5, więc nawet, mimo że nie ma pozycji MAINTAINERS w agpgart, to będzie chyba odpowiednim adresatem łat. :) Mimo że agpgart w 2.5 jest inne, davej ma o tym pojęcie i mógłby prawdopodobnie zaakceptować lub nanieść łaty z 2.4..."

Marc-Christian Petersen nadesłał łatę IDE dla 2.4 i J.A. Magallon zapytał: "czy to znaczy, że IDE Andre trafia do 2.4.21-pre1?" Marc-Christian potwierdził, że tak się właśnie stało, z głośnym: "Nareszcie!!!!!!!!! :-))" Alan Cox również to potwierdził i dodał: "Mimo że różne rzeczy zniknęły w czasie nadsyłania (fragmenty system.h i ide-scsi). Davem ma trochę dodatkowych rzeczy, które muszę nanieść (nowe IDE zepsuło jakąś dziwną 64-bitową bigendianową platformę, którą on obsługuje 8))"

Dokument ten jest regularnie przesyłany na lkml i zostanie zmieniony, gdy tylko nowa ofiara zażyczy sobie, aby ją dodać albo ktoś nie może już więcej poświęcać czasu na pracę opiekuna.

Jeśli chesz, aby dodać/uaktualnić/usunąć Twoje dane, skontaktuj się ze mną.

Przy okazji, żądania przeniesienia swojego nazwiska na szczyt listy bez żadnej zmiany tekstu są w porządku: oznacza to, że dane się nie przedawniły, nie bądźcie więc nieśmiali ;-)

Dostępna jest wersja 0.1.0 zestawu testów Open POSIX: http://posixtest.sourceforge.net. Ta wczesna wersja zawiera tylko małą część testów docelowych. Zawiera testy zgodności dla liczników czasu POSIX, znaczników TMR i CS (z wyjątkiem THR CS). Notka do tej wersji, pojawiająca się podczas pobierania instruuje, gdzie znaleźć informacje na temat kompilacji i korzystania z testów.

README oraz strona www zestawu testów Open POSIX (powyżej) dają więcej informacji o celach i postępach, jak również zawierają informacje jak pomagać, lub skontaktować się z nami, jeśli jesteście zainteresowani.

Zestaw testów Open POSIX jest zestawem testów o otwartych źródłach mającym na celu przeprowadzanie testów zgodności, funkcjonalności i wytrzymałości na obciążenia na funkcjach opisanych w specyfikacji interfejsów systemowych IEEE Std 1003.1-2001. Pożądane byłoby przeprowadzanie testów wszystkich intrefejsów ze specyfikacji, wstępne prace skupiają się jednak na licznikach czasu, kolejkach wiadomości, wątkach, semaforach i sygnałach.

Opublikowano LTP-20021210.tgz - wersję 20021210 projektu Linux Test. Odwiedź naszą stronę (http://ltp.sourceforge.net), aby pobrać najnowszą wersję zestawu testów, a także aby zasięgnąć informacji o wynikach testów na przedwydaniach, kandydatach do pełnych wydań oraz stabilnych wersjach jądra. Jest również lista przypadków, co do których spodziewamy się, że zawiodą, proszę poszukać tej listy na (http://ltp.sourceforge.net/expected-errors.php)

Najważniejsze rzeczy związane z tą wersją:

Wiele nowych testów z Wipro.
Przeniesiono nowe testy SPIE. Szczególne podziękowania dla Gerrit Huizenga i Narasimha Sharoff za zdobycie dla nas testów SPIE.

Zachęcamy do nadsyłania wyników testów, łat lub nowych testów na naszą listę dyskusyjną oraz do używania naszego systemu śledzenia błedów z CVS-a, aby powiadamiać o napotkanych problemach. Więcej szczegółów na naszej stronie.

Rozpoczęły się prace nad stabilizacją. Na zainteresowanie zasługuje uaktualnienie API framebuffera/konsoli. Pełna lista dostępna jest na http://www.kernelnewbies.org/status/.

Ponieważ coraz więcej osób testuje różne konfiguracje, liczba błędów na bugzilli znacznie wzrosła od ostatniego tygodnia do 80 i ciągle przybywają nowe.

Rik i ja z przyjemnością ogłaszamy procps w wersji 2.0.11, pakiet zawierający ps, top, free, vmstat, etc.

Nowsze wersje procps są wymagane dla jąder z serii 2.5.

Najważniejsze w tej wersji jest naprawienie kilku błędów, obsługa /proc/pid/wchan i zupełnie nowa implementacja free(1).

Paczka ze źródłami oraz pakiety RPM mozna pobrać z:
http://tech9.net/rml/procps/

Wszelkie rozmowy na temat procps, powiadomienia o błędach i łaty proszę przesyłać na adres:
procps-list@redhat.com

NOWOŚCI w 2.0.11:

dodano pole CPU w top (Dave Miller)
zapewnienie, że umieszczenie statystyk CPU jest zawsze wyrównane (Rik van Riel)
usunięcie dzielenia przez zero w vmstat (Jens Axboe)
obsługa przed-dekodowanego wchan z 2.5 w /proc/#/wchan (Robert Love)
oczyszczenie makefile (Maciej W. Rozycki)
usunięto z pakietu XConsole (Robert Love)
usunięto kill i kill.1, są teraz w util-linux (Robert Love)
poprawiono znaczące literówki (Chris Rivera)
całkiem nowa implementacja free (Robert Love)
poprawione print_uptime i sprint_uptime (Robert Love)
domyślne uprawnienia po instalacji to 755 (Robert Love)


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	2 Dec 2002 - 9 Dec 2002	(20 posts)	Poprawki ACPI opóźnione w 2.4
2.	2 Dec 2002 - 7 Dec 2002	(18 posts)	Uaktualnienie i stan framebuffera
3.	3 Dec 2002 - 11 Dec 2002	(78 posts)	Warstwa zgodności wołań systemowych
4.	4 Dec 2002 - 9 Dec 2002	(40 posts)	Przyszłość rozwoju Linuksa
5.	4 Dec 2002 - 7 Dec 2002	(90 posts)	API dla nie-PCI DMA
6.	6 Dec 2002 - 9 Dec 2002	(11 posts)	Zmiana licencjonowania ACPI
7.	6 Dec 2002	(1 post)	User-Mode Linux uaktualniony do 2.5.50
8.	7 Dec 2002	(2 posts)	Obsługa karty AGP VIA 8633
9.	7 Dec 2002	(4 posts)	Obsługa zintegrowanej karty dźwiękowej 8233
10.	7 Dec 2002 - 9 Dec 2002	(5 posts)	Nowy kod podsystemu IDE włączony do 2.4
11.	9 Dec 2002	(1 post)	Lista opiekunów jądra
12.	10 Dec 2002	(1 post)	Zestaw testów POSIX 0.1.0 opublikowany
13.	10 Dec 2002	(1 post)	Opublikowano wersję 20021210 projektu Linux Test
14.	10 Dec 2002	(1 post)	Nowa lista stanu dla 2.5
15.	11 Dec 2002	(2 posts)	Opublikowano procps 2.0.11

Kernel Traffic #196 For 2002/12/16

By Zack Brown

Translated By: Damian Wojsław , Maja Królikowska and Paweł Kot