Kernel Traffic #145 For 10 Dec 2001

Wróciła wyszukiwarka. Kir Kolyshkin i Alexander F Avdonkin wspaniałomyślnie skonfigurowali silnik aspseek tak, aby indeksował nasze strony. Aspseek to firma, która oferuje swoją wyszukiwarkę na zasadach GPL. Obiecali, że jedyny baner reklamowy, który pojawi się na stronach z wynikami wyszukiwania będzie prowadził do ich stron, co dla mnie nie stanowi problemu.

There were 589 different contributors. 274 posted more than once. 242 posted last week too.

Jeremy Elgar spytał, czy są jakiekolwiek problemy z wykorzystywaniem łat z wywłaszczaniem jądra razem z łatami na XFS. Bill Dunn sądził, że Jeremy przypuszczalnie będzie musiał trochę podopieszczać te łaty tak, aby współgrały ze sobą, co, jak uważał, jest zawsze konieczne przy nakładaniu wielu łat na jądro. Ale Michael Dunsky i Anuradha Ratnaweera zgłosili, że używają takich jąder już od jakiegoś czasu i nie zanotowali żadnych problemów. Dla pełnego obrazu sytuacji, Robert Love dodał: "Jedynym zgłoszonym problemem był błąd kompilacji, który naprawił Keith Owens pokazując poprawkę. Jeśli będziesz miał problemy, to je zgłoś, a my postaramy się pomóc."

Pomiędzy innymi pytaniami, Gerard Roudier spytał Marcelo Tosattiego: "Tak przy okazji, nie zauważyłem żadnych wiadomości, które uczyniły Cię opiekunem 2.4, ani nie widziałem komentarzy Alana na ten temat. Jestem pewien, że będziesz się starał, i że będziesz wykonywał kawał dobrej roboty, ale czuję się nieco sfrustrowany nie znając motywów tej decyzji. Jeśli możesz mi wskazać artykuły dotyczące tego, będę zobowiązany." Christophe Barbe wskazał Gerardowi wpis na Advogato autorstwa Alana Coksa, a Gerard odpowiedział, że te informacje go satysfakcjonują. Ale Mike Fedyk powiedział: "To, tak naprawdę, nie pokazuje, *dlaczego* został wybrany. Nie było zbyt wielu informacji o Marcelo w przeszłości." Dodał: "Tak, to z zewnątrz wygląda na dużą zmianę. Nawet dla czytelników LKML ;)"

Marcelo również odpowiedział na pytanie Gerarda, wskazując na wpis na Advogato i mówiąc: "Cóż, wygląda na to, że Alan ma dość opieki... :)"

Ktoś doświadczył kilku błędów kompilacji, gdy starał się przetestować 2.5.1-pre2, a Linus Torvalds odpowiedział:

Tak.

Do drzewa 2.5.x została włączona pierwsza porcja łat dla warstwy nowej generacji obsługi urządzeñ blokowych, która to jest niezgodna ze starymi sterownikami, które nie zostały zaktualizowane do nowego sposobu blokowania.

W szczególności, do tej pory była tylko _jedna_ blokada w całym systemie WE/WY (,,io_request_lock''), a aktualnie jest jedna blokada na kolejkę urządzenia blokowego.

W wielu przypadkach poprawka ogranicza się do zastąpienia ,,io_request_lock'' przez ,,host->host_lock'', ale czasami jest bardziej skomplikowana i wymaga przekazania odpowiednich struktur danych dostatecznie głęboko.

Wiele sterowników zostało przekonwertowanych (np. IDE, symbios, aic7xxx itp.), ale o wiele więcej nie zostało (zwłaszcza stare sterowniki SCSI, w Twoim przypadku jest to klasyczne aha1542).

Przypuszczalnie upłynie trochę czasu, zanim większość sterowników zostanie skonwertowana. Przetestowane łaty są bardziej niż mile widziane.

Christoph Hellwig zasugerował, że ponieważ i tak psują obsługę SCSI, to chciałby wysłać łatę, która "usunie stary (2.0) system obsługi błędów scsi tak, aby wymusić poprawki na używających go sterownikach. Wczesne jądra 2.5 wyglądają mi na dobry moment na to." Robert Love poparł ten pomysł, a Linus powiedział: "Zgadzam się, to wygląda na dobry pomysł, tym bardziej, że obsługa urządzeñ blokowych będzie jedną z rzeczy, które ulegną znacznym przeobrażeniom w 2.5.x i, co za tym idzie, będzie to jedna z ważniejszych zmian w tej serii jądra." Christoph wysłał łatę, a następnie on, Andreas Dilger i Martin Dalecki odbyli krótką techniczną dyskusję na jej temat.

Paul Mackerras odpowiedział Linusowi, pytając: "Czy jest gdzieś opis nowej warstwy obsługi urządzeñ blokowych i interfejsu do sterowników takich urządzeñ? Byłoby to dość użyteczne, ponieważ Ben Herrenschmidt i ja chcemy przekonwertować kilka sterowników specyficznych dla powermaca." Daniel Phillips podał odnośnik do http://lse.sourceforge.net/io/bionotes.txt, a Linus potwierdził, że to jest właśnie dokument, przez który trzeba się przegryźć. Kilka osób przedyskutowało pomysły opisane w tym dokumencie.

To jest pierwsza publiczna wersja mojego nowego api dla framebuffera. Podstawowym celem jest usunięcie całego niepotrzebnie duplikowanego kodu i umieszczenie całego kodu związanego z konsolą w fbcon.c. Drugim celem jest umożliwienie istnienia warstwy framebuffera bez systemu konsoli. W urządzeniach osadzonych, które nie posiadają klawiatury, nie ma to sensu, a dodatkowo wkompilowanie systemu VT zajmuje nieco wartościowego miejsca. Trzecim i ostatnim celem jest ułatwienie i uelastycznienie zapisu sterownikowi fbdev.

Ta łata pokazuje 3 proste rzeczy, które chciałbym zmienić.

Uniweralne api kursora. To pozwoli uniknąć rejestrowania i programowania kursora dla każdej dostępnej karty. Pozwoli na oddzielenie fbdev i fbcon.
Przeniesienie podstawowego kodu framebuffera do kodu silnika przyspieszającego. Umożliwi to całkowite usunięcie kodu konsoli z niskopoziomowych sterowników framebuffera i będziemy mogli się pozbyć tych, wołających o pomstę do nieba, plików fbcon-cfb*. Zatem skoñczy się to znaczną redukcją kodu, co spowoduje, iż operacja zapisywania w sterownikach fbdev będzie znacznie szybsza. Zauważcie, że to są podstawowe zmiany, wymagane przez warstwę fbdev. Nie są jednak w żaden sposób wykorzystywane z przestrzeni użytkownika. To oznacza także, że będziemy mieli 3 proste funkcje, zamiast 7, zawartych w display_switch.
Usunięcie zduplikowanego kodu. Przykładami są funkcje fb_cmap, które są w zasadzie takie same w każdym sterowniku. Zobaczycie zatem wkrótce fbgen2, w którym będzie ten sam kod, który jest duplikowany w każdym sterowniku.

Geert Uytterhoeven i Petr Vandrovec mieli kilka technicznych komentarzy i przez chwilę o tym podyskutowali.

David C. Hansen wysłał łatę, która usuwa dużą blokadę jądra (BKL, big kernel lock) z wielu miejsc w sterownikach w drzewie 2.5. Wyjaśnił: "Większość z tych łat po prostu usuwa BKL z pliku. Nie powoduje to żadnych problemów, ponieważ BKL, tak naprawdę, nic nie chroniło. Inne łaty próbują wykonać prawdziwe blokowanie. Niektóre wykonują to z wykrzystaniem operacji atomowych w funkcjach atomic_*, inne -- w funkcjach (test|set)_bit. Większość łat zastępuje użycie zwykłych integerów, używanych do trzymania liczników otwarcia w sterownikach. W niektórych przypadkach zostały dodane blokady na SMP, gdy atomowe operacje nie były w stanie zapewnić poprawnej kolejności wywołania. W nielicznych przypadkach, istniejące blokady zostały rozszerzone tak, aby chronić więcej rzeczy. Te przypadki są naprawdę rzadkie, bowiem blokowanie jest bardzo rzadkim przypadkiem w tych sterownikach." Następnie odbyła się dyskusja, z której wynikło, że pozbycie się BKL jest w każdym wypadku dobrą rzeczą.

Tym razem wiele zmian w sterownikach...

Chciałbym także wiedzieć, czy ktoś odczuje jakąś różnicę w interaktywności przy dużych obciążeniach WE/WY.

pre2:

Usunięcie nagłówka z przestrzeni użytkownika w sterowniku bonding (David S. Miller)
Stworzenie SLAB do tablicy stron na i386 (Christoph Hellwig)
Wyrejestrowanie urządzeñ przy wyładowaniu shapera (David S. Miller)
Usunięcie nieużywanych zmiennych z różnych miejsc w jądrze (David S. Miller)
Poprawka w kodzie slab tak, aby nie ufać ślepo cc_data(), które może być niepoprawne na niektórych platformach (David S. Miller)
Poprawka błędu w sterowniku RTC (David S. Miller)
Uaktualizacja SPARC 32/64 (David S. Miller)
Aktualizacja sterownika W9966 V4L (Jakob Jemi)
Poprawki w sterowniki ad1848 (Alan Cox/Daniel T. Cobra)
Aktualizacja PCMCIA (David Hinds)
Poprawka problemu z PCMCIA i wieloma magistralami PCI (Paul Mackerras)
Poprawne zwalnianie struktury signal dla procesu (Dave McCracken)
Czyszczenie plików nagłówkowych IA64 PAL/signal (Nathan Myers)
Czyszczenie sterownika ymfpci (Pete Zaitcev)
Zmiana ,,licencji'' NLS na ,,GPL/BSD'', zamianst zwykłego BSD. (Robert Love)
Poprawka w użyciu licznika w module obsługi portu szeregowego (Russell King)
Aktualizacja sg do 3.1.22 (Douglas Gilbert)
Aktualizacja ieee1394 (Ben Collins)
Poprawki ReiserFS (Nikita Danilov)
Aktualizacja dokumentacji ACPI (Patrick Mochel)
Sprytniejsze aktualizacje atime (Andrew Morton)
Poprawne oznaczanie superbloku ext2 jako brudnego i opróżnianie buforów (Andrew Morton)
Aktualizacja IrDA (Jean Tourrilhes)
Licznik blokował bufory przy balance_dirty_state(): Poprawia interaktywność przy dużym obciążeniu WE/WY (Andrew Morton)
Aktualizacja USB (Greg KH)
Poprawka przy blokowaniu ide-scsi (Christoph Hellwig)

Patrick Dijkkamp zauważył, że Marcelo zapomniał uaktualnić numeru wersji tak, jak to miało miejsce w poprzednim tygodniu.

Justin Wells spytał, czy nie znalazłby się jakiś sposób na oznaczanie jąder na kernel.org, tak aby użytkownicy wiedzieli, które wersje są lepsze niż inne. Mike Fedyk zaproponował, aby Justin zgłosił się na ochotnika do oceniania, jak dobre były kolejne jądra, ale Willy Tarreau powiedział:

no cóż, istnieje bardzo prosty sposób, aby uzyskać wartościową informację: instalacja systemu głosowañ w serwisie www (kernel.org...) tak, aby ludzie, którzy pobierają nowe jądro mogli także powiedzieć, którego jądra używają, przybliżony uptime, jaki mają, czy doświadczyli jakichś problemów, czy musieli je łatać, aby osiągnąć stabilność, oraz, być może, co z tym robią (wewy/sieć/stacja robocza/wszystko).

Kolejnym krokiem byłaby ocena różnych łat krążących po sieci w ten sam sposób. *Są* sposoby na uzyskanie stabilnego jądra, nawet teraz, dla danego zastosowania. Oczywiście, nie każdy ma te same potrzeby, ale to mogłoby dać opiekunom trochę pojęcia na temat, które łaty mogą być włączone przy stosunkowo niewielkim ryzyku.

Sądzę, że jeśli choćby jedna dziesiąta subskrybentów LKML oceniała swoje jądra przynajmniej raz w tygodniu, szybko zobaczylibyśmy stabilne i niestabilne jądra.

Mike'owi spodobał się ten pomysł, a Ian Stirling dodał: "W przeszłości proponowałem rozszerzoną wersję tego. make register, czy coś w tym stylu. Gdy wykonasz to polecenie, pobierana jest migawka z konfiguracji systemu, opcjonalnie z komentarzami, i jest ona wysyłana do rejestru. Możesz wówczas wykonać make comment i zgłosić parę spraw. Te komentarze mogłyby być różne, od ,,wysypuje się'' do ,,mój twardy dysk umarł/umiera''. Zatem uzyskiwalibyśmy informację o systemie, oraz o tym czy, i jak działa."

Stworzyłem robota na kernel.org, który tworzy i udostępnia przyrostowe łaty dla jąder testowych. Szuka standardowo nazwanych łat testowych w katalogach /pub/linux/kernel/v*.*/testing i tworzy przyrostowe łaty w odpowiadających im katalogach /pub/linux/kernel/v*.*/testing/incr.

Dla przykładu:

hera 86 % cd /pub/linux/kernel/v2.5/testing/incr/
hera 87 % ls -l *.gz
-rw-rw-r--    1 kdist    kernel     177158 Nov 27 10:17
patch-2.5.1-pre1-pre2.gz
-rw-rw-r--    1 kdist    kernel     102202 Nov 28 15:35
patch-2.5.1-pre2-pre3.gz
-rw-rw-r--    1 kdist    kernel      52955 Nov 29 15:29
patch-2.5.1-pre3-pre4.gz
-rw-rw-r--    1 kdist    kernel      53616 Nov 30 17:04
patch-2.5.1-pre4-pre5.gz

Nazewnictwo i funkcje łat powinny być oczywiste.

Pliki .bz2 i .sign są oczywiście również dostępne.

Kilka osób umarło ze szczęścia, a Matt Domsh spytał: "Nie chciałbyś może zorganizować listy podobnej do kdist, na którą wysyłane byłyby: lista zmian, statystyka różnic oraz przyrostowa łata, jako wynik działania tego skryptu? Zwiększyłoby to użyteczność komentarzy takich, jak ,,Alan -- dalszy ciąg łączenia'' w listach zmian. Również skrypt do aktualizacji strony www a la www.bzimage.org znacznie ułatwiłby wyszukiwanie łat. Jestem ochotnikiem do pomocy, jeśli chcesz." Nie było odpowiedzi na tę propozycję, ale gdzie indziej, Anders Peter Fugmann zasugerował H. Peterowi: "Czy mógłbyś (gdy będziesz miał czas) rozszerzyć system tak, aby robił również łatę pomiędzy ostatnią wersją testową oraz wersją ostateczną?" H. Peter odpowiedział, że miał zamiar to zrobić, ale o tym zapomniał. Dodał to dość szybko, a Anders odpowiedział: "Teraz jest już idealnie."

Zwane Mwaikambo miał kilka łat czyszczących kod OSS. Wiedział, że OSS zostanie wkrótce zastąpione przez ALSA i spytał, czy dalsza praca nad OSS jest warta jego zachodu. Alan Cox odpowiedział: "Cóż, jeśli wykonałeś już kawałek tej pracy, to czemu nie -- ludzie będą używać 2.4 jeszcze przez długi czas. Zmiany w PM mogą być także odpowiednie dla ALSA."

W pewnym momencie John Gluck spytał, czy ALSA znajdzie się w 2.4. Jeff Garzik powiedział: "IMHO ALSA -nigdy- nie powinna znaleźć się w 2.4. Jest bardzo przyjemna jako łata, ale to 2.5 jest miejscem na duże zmiany, a ponieważ ALSA jest już dostępna dla 2.4 poza oficjalnym jądrem -- nie powinno być potrzeby przenoszenia jej z 2.5 do 2.4."

Hans-Christian Armingeon sputał, czy lista dyskusyjna linux-kernel umarła, a Ragnar Hojland Espinosa potwierdził, że "coś ostatnio z nią nie tak.." Matti Aarnio wyjaśnił:

Powiedziałbym, ,,że to jest niedomówienie''...

Z kilku powodów, próbowaliśmy przenieść vger do innej przestrzeni adresowej. Jednakże projekt ten zaowocował duża ilością nieudanych zapytañ DNS, które pomimo zwracanego statusu ,,BEZ BŁĘDU'', nie przekazywały żadnych danych.

Przywrócenie vger starego adresu również po części się nie udało i trzeba się było mocno nagimnastykować, żeby naprawić ten bałagan.

Motywem tak drastycznej operacji przeadresowania jest to, iż niektóre systemy uważają za słuszne odrzucać pocztę tylko dlatego, że zapytania DNS przekraczają tam dopuszczalny czas oczekiwania (bez próby produkowania kodów błędów z serii 400).

Niektórzy ludzie (MNóSTWO ludzi) uważają, że właściwą rzeczą jest analizować wartość parametru przekazywaną do powitalnego EHLO/HELO. ISP'y wiedzą, że po prostu nie mogą tego robić, świat jest pełen popsutych MUA (z jakiegoś powodu, zazwyczaj w systemach M$), które próbują dostarczyć pocztę przez huby ISP.. Spam-serwery zazwyczaj rozumieją tę część.

Niektórzy ludzie uważają, że słuszne jest choćby myślenie o analizowaniu, iż adres IP klienta SMTP ma działający wpis w strefie odwrotnej DNS. (Połączcie to z nieudanym obchodzeniem się z przekraczanym czasem odpowiedzi..)

CONFIG_DEBUG_SPINLOCK dodaje jedynie testy blokad przy kompilacjach na komputery wieloprocesorowe. Załączona łata dodaje takie sprawdzanie również na maszynach jednoprocesorowych.

Przetestowana na i386/UP, ale powinna działać na wszystkich platformach. Zawiera sprawdzanie:

brakującej inicjalizacji
rekursywnej blokady
podwójnego zwalniania blokady
niepoprawnego użycia spin_is_locked() i spin_trylock() [obie funkcje nie działają tak, jak możnaby się spodziewać w systemach jednoprocesorowych]

Następny krok to sprawdzanie niewłaściwej kolejności blokad.

Jakie inne sprawdzenia mogą zostać wykonane? Testy poprawności użycia _irq nie są możliwe, kilka sterowników używa disable_irq().

Marcelo Tosatti ogłosił 2.4.17-pre3 i powiedział: "Osoby z Pentium Pro są proszone o przetestowanie, czy zastosowane obejście działa poprawnie..." Alex Buell spytał: "Gdzie są poprawki dla sparca? Są jeszcze poprawki, które czekają od 2.4.16, a które naprawdę powinny zostać włączone!" Marcelo poprosił Aleksa o wysłanie łat do niego, a David S. Miller odpowiedział: "Wysyłałem Ci już je dwa razy. Gdy tylko dostosuję łaty do 2.4.17pre4, wyślę je ponownie."


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

1.	26 Nov 2001 - 2 Dec 2001	(5 posts)	Używanie XFS z wywłaszczalnym jądrem
2.	27 Nov 2001 - 1 Dec 2001	(8 posts)	Krótka dyskusja, dlaczego Marcelo jest opiekunem 2.4
3.	27 Nov 2001 - 1 Dec 2001	(34 posts)	Odnowienie warstwy obsługi urządzeñ blokowych w 2.5
4.	28 Nov 2001 - 30 Nov 2001	(6 posts)	Nowe API dla framebuffera dla jąder 2.5
5.	28 Nov 2001 - 1 Dec 2001	(26 posts)	Usuwanie BKL z 2.5
6.	30 Nov 2001	(2 posts)	Jądro 2.4.17-pre2 na wolności
7.	30 Nov 2001 - 2 Dec 2001	(13 posts)	Identyfikacja dobrych wersji jądra
8.	1 Dec 2001 - 3 Dec 2001	(9 posts)	Przyrostowe łaty dla jąder testowych są już dostępne
9.	3 Dec 2001 - 5 Dec 2001	(18 posts)	Migracja z OSS do ALSA
10.	3 Dec 2001 - 4 Dec 2001	(3 posts)	Problemy z listą dyskusyjną linux-kernel
11.	3 Dec 2001 - 5 Dec 2001	(17 posts)	Poprawione debugowanie blokad w systemach jednoprocesorowanych
12.	5 Dec 2001 - 6 Dec 2001	(8 posts)	Opieka nad 2.4

Kernel Traffic #145 For 10 Dec 2001

By Zack Brown

Translated By: Jakub Jankowski and Paweł Kot