Kernel Traffic #121 For 11 Jun 2001

W zasadzie to Linus lub Alan powinien odpowiedzieć na to, ale z mojego punktu widzenia sytuacja wygląda następująco:

Alan i Linus nie zawsze zgadzają się co do zawartości jądra; a nawet jeśli się zgadzają, to bywają różnice zdañ na temat, kiedy można coś włączyć do jądra. W szczególności Alan może uważać, że pewne łaty są już na tyle dobre żeby wejść do jądra, a Linus uważa, że trzeba jeszcze trochę nad nimi popracować; albo nawet, że samo podejście to tematu jest złe i niewarte uwagi. W takim wypadku Alan włącza te łaty do swojego jądra, a Linus je ignoruje. (Oczywiście, czasem bywa odwrotnie - Linus akceptuje łatę, podczas gdy Alan ją odrzuca.) Jeśli czasem, któryś z tych nowych pomysłów rozwinie się ponad oczekiwania (zwłaszcza po kilku cyklach usuwania błędów), osoba, która odrzuciła łatę zmienia zdanie i w koñcu ją włącza do swojej gałęzi; albo gdy łata okaże się niewypałem - w koñcu zostanie odrzucona przez obu. Oprócz tego, jak pewnie zauważyłeś, Alan regularnie synchronizuje swoją gałąź z gałęzią Linusa, więc ich drogi zbyt daleko się nie rozejdą. Linus okazjonalnie robi to samo.

Na początku też mnie to dziwiło. Musiałem być na bieżąco z obiema gałęziami. Ale w koñcu zrozumiałem, że to Dobra Rzecz. Pozwala na działanie ludziom z różnymi pomysłami i podejściami do rozwoju jądra. Jeśli jeden problem jest rozwiązywany na dwa różne sposoby w dwóch gałęziach, to przekonamy się naocznie jak te rozwiązania sprawdzają się nie tylko w teorii, ale i w praktyce. Gdyby drogi gałęzi zbytnio się rozeszły, powstałby problem, ale Linus i Alan pilnują, aby tak się nie stało. Myślę, że gra (,,współzawodnictwo'' to raczej zbyt mocne słowo) pomiędzy gałęziami znacznie pomogła w rozwoju jądra.

No cóż, tak naprawdę to się zaczęło przez przypadek, ale okazało się, że dobrze jest mieć gałąź, do której łatwiej przenikają zmiany, są tam testowane przez osoby mające problemy i oceniane przez innych, zanim zawędrują do oficjalnego jądra Linusa.

Tak więc jądra -ac są rodzajem poligonu doświadczalnego dla nowych łat.

• Nowa opcja przy montowaniu show_sys_files=<bool> pokazująca pliki systemowe jako zwykłe pliki.
• Wsparcie dla plików i w ogólności wszystkich atrybutów aż do maksymalnego rozmiaru oferowanego przez NTFS - 2TB. Uwaga: wsparcie obejmuje jedynie i-węzły/klastry o wartościach maksymalnie 32-bitowych.
• Wsparcie dla większych niż 128KB runlist (przy użyciu vmalloc_32() zamiast kmalloc()).
• Usunięty wyścig procesów przy alokowaniu klastrów i rekordów mft.
• Usunięty poważny błędy przy obsłudze / przeszukiwaniu / porównywaniu atrybutów.
• Usunięty poważny błąd przy kompresowaniu runlisty do tablicy mapujących par.
• Usunięty poważny błąd przy alokacji i-węzłów. Zwłaszcza przy tworzeniu pliku i katalogu.
• Usunięte wycieki pamięci.
• Poprawione mnóstwo innych błędów...
• Poprawione błędy znalezione przez Stanford checker w ntfs_dupuni2map() i ntfs_get_free_cluster_count().
• Nowy system wersjonowania, ponieważ ten oparty na dacie był zbyt niejasny... (wersje wcześniejsze niż 1.1.15 nie były publikowane, więc żadnej nie straciliście).

• Nie należy używać tego sterownika do zapisywania na partycji NTFS - może to spowodować uszkodzenie systemu plików. Jeśli jednak tak się stanie należy zaopatrzyć się w narzędzia Linux-NTFS i użyć programu ntfsfix po odmontowaniu partycji.
• Należy używać "ls -l" zamiast "ls". W przeciwnym razie ostatnia pozycja w niektórych katalogach nie jest wyświetlana. (?!?)
• Zalecane jest używanie opcji show_sys_files przy montowaniu, która powoduje, że wszystko działa lepiej.
• Znaki specjalne są źle obsługiwane. Na przykład, jeśli nazwa pliku zawiera apostrof, nie da się go otworzyć.
• Zapisywanie rekordów rozszerzeñ nie jest poprawnie obsługiwane.

Problemy z VIA nie wynikają z błędów w sprzęcie. Błędy są wszędzie. Jeśli mam problem z jakimś chipsetem Intela idę na developer.intel.com i zazwyczaj dostaję tam odpowiedź, jak obejść problem. To mnie cieszy. Problemem nie jest błąd, ale uczciwość w dawaniu informacji o nim.

Gdyby VIA opublikowało listę błędów zawierającą takie rzeczy jak: ,,wybór pakietu z wyprzedzeniem może spowodować błędy jeśli nie ustawi się trzeciego bitu w blah'' bylibyśmy w stanie zapanować nad tym co się dzieje i ludzie mogliby podejmować sensowne decyzje i mieć wartościowy kod.

Intel też nie jest doskonały. Mamy całe mnóstwo laptopów, które się wywalają gdy zajdą sytuacje, których nie umiemy obsłużyć. Mamy problem z APIC, który kosztował już dużo wysiłku, ponieważ Intel odmówił pomocy.

Gdy uzyskuje się pomoc od producenta, życie staje się prostsze. Był problem z USB AMD. Gdy zostały opublikowane poprawki problem znikł.

Wygląda na to, że problem jest spowodowany błędem związanym z DMA w chipsecie VIA lub w linuksowym sterowniku VIA DMA-IDE. Udało mi się uniknąć padów systemu gdy skompilowałem jądro bez wsparcia dla DMA w urządzeniach IDE. Teraz hdparm pokazuje, że dyski nie używają DMA a system działa stabilnie. Tyle na razie mogę powiedzieć.

W ciągu ostatnich kilku dni prowadziłem intensywne testy i nie byłem w stanie doprowadzić do zwisu. Przez 12 godzin wiele współbieżnych procesów kopiowało gigabajty danych pomiędzy dyskami, procesor był zajęty szyfrowaniem danych, a system cały czas działał. Dla celów diagnostycznych przełączyłem się z powrotem na 2.2.19 z włączonym IDE-DMA. System się wykopyrtnął. Wynika z tego, że rzeczywiście chodzi o problem z DMA.

W BSD, w select(), gdy wystąpi timeout, bity przekazane do selecta nie zostaną zamienione. W Linuksie, który podobno jest zgodny z BSD (wg. stron manuala, które jednak nie mówią co się stanie z bitami), te bity są zerowane w przypadku timeoutu. Napisałem przykładowy program, aby to przetestować i uruchomiłem na obu systemach; BSD zachowywało się tak jak miało, a Linux inaczej niż BSD.

Czy strony manuala nie powinny być zmienione aby odzwierciedlić stan rzeczywisty, bądź select() nie powinien być poprawiony tak, aby zachowywał się, jak w BSD?

Kilka tygodni temu obiecałem Jeffowi Garzikowi, że napiszę dokumentację do procfs i oto właśnie ona. Ten przewodnik jest napisany w DocBook SGML-u i mówi o tym jak używać procfs z wewnątrz jądra.

Ciągle szukam właściwego sposobu na automatyczne włączenie przykładowych źródeł w plik SGML, łata z tą samą zawartością w obu plikach jest okropnym przykładem.

Ta łata jest zgodna z linux-2.4.5, ale powinna dać się użyć także z 2.4.5-ac*.

Tak właśnie jest, przekazałem je właśnie do włączenia do krenela, ale ich tam jeszcze nie ma. Zaaplikuj moją łatę na swój kod źródłowy jądra, uruchom ,,make psdocs'' i będziesz miał to w swoim drzewie jądra.

Jakkolwiek, ponieważ na liście kernelnewbies pojawiły się podobne pytania o procfs, zdążyłem umieścić online wersję html i pdf na stronach z dokuentacją kernelnewbies:

http://www.kernelnewbies.org/documents/kdoc/procfs-guide/lkprocfsguide.html

Mam wielką przyjemność ogłosić, że plik Configure.help jest już pełny, dla 2.4.5. Każdy z 2699 symboli konfiguracyjnych używanych w źródłach pisanych w C lub w Makefilach ma swoje odzwierciedlenie w Configure.help.

Nie oznacza to oczywiście, że zakoñczono pracę nad utrzymywaniem Configure.help; symbole będą dodawane i odrzucane w przyszłości (jest wiele nowych w ac5, teraz już udokumentowane), a niektóre z istniejących mogą wymagać przepisania i rozszerzenia. Przekroczyliśmy jednak kamieñ milowy -- utrzymywanie go będzie teraz kwestią zapewnienia gwarancji, że łódź nie utonie, a nie próbą ignorowania dziury w burcie.

Dziękuję wszystkim, którzy przyczynili się do złożenia wszystkich 550 elementów potrzebnych do tego osiągnięcia, zbyt wielu ich jest by wymieniać. Wynik jest dostępny pod adresem:

http://www.tuxedo.org/~esr/cml2/Configure.help.gz

Jakkolwiek znajduje się on na stronie projektu CML2, może być używany również z CML1, zarówno z jądrami Linusa, jak też i Alana.

Mam teraz dwie prośby do Linusa i Alana:

1. Proszę, weźcie pod uwagę wykonaną przez nas pracę. Jest to naprawdę ważna poprawka w porównaniu z tym co znajduje się w waszych drzewach, włączenie jej niczego nie zepsuje, a pomożecie uniknąć niepotrzebnych kłopotów spowodowanych rozbieżnymi łatami w przyszłości.
2. Wprowadźcie proszę politykę odrzucania łat, które dodają nowe symbole konfiguracyjne bez dodania wyjaśnienia do Configure.help -- i proszę *ogłaszajcie*, że to robicie. Możemy teraz wypracować standardy i uważam, że powinniśmy to zrobić, by mieć dobrze udokumentowane jądro i system konfiguracyjny.

Imho, procfs powinien być tylko dla informacji o procesach, nie powinien służyć do niczego więcej. Procfs, w obecnej formie, jakkolwiek użyteczny, jest czymś okropnym, co powinno zostać wyprowadzone gdzieś na podwórko i zastrzelone na śmierć.

Ehrmmm. Mówiąc poważnie, wszystko co nie jest związane z informacją o procesach powinno być oddzielone od procfs. Może trzeba by to nazwać kernfs, albo jakoś inaczej.

Nie zgadzam się z tymi, którzy twierdzą, że 2.4.xx jest złe, albo wciąż w fazie beta.

Wciąż jest ryzykownym używanie tych jąder na GŁóWNYCH 24x7 produkcyjnych serwerach.

To jest prawdą dla 1.2.x, 2.0.x (w mojej opinii to najlepsza seria jąder), 2.2.x i 2.4.x i tak samo będzie dla 2.6.x.

Zakładając, że wiemy, że wsparcie ze strony developerów open source jest wyraźnie lepsze niż wsparcie wynikające z kontraktów handlowych, nie widzę powodu aby narzekać na pracę wspaniałych hakerów, którzy spędzają swój wolny czas pisząc kod dostępny dla nas wszystkich.

Jestem zmuszony się zgodzić. Używam 2.4.x i z małymi wyjątkami (HP/APIC, z work-around), nie miałem żadnych problemów z żadnym z używanych przeze mnie jąder z serii 2.4.x.

Wolne oprogramowanie, z definicji, nigdy nie osiągnie takiej "monolitycznej" stabilności jaką może osiągnąć oprogramowanie zamrażane na długie lata. Linux (a szczególnie 2.4.x) oferuje zbyt dużo w zamian a ja zawsze mogę użyć 2.2.x. Chciałbym powiedzieć, że stabilność jądra jest *powyżej* moich oczekiwañ, szczerze, biorąc pod uwagę wszystkie zmiany.

Oczywiście my, jako admini, jesteśmy odpowiedzialni za testowanie tych jąder. Miałem okazję używać 2.4.0-test1 i znalazłem jeden problem, który był zgłaszany i sprawdzany (najwyraźniej był ciężki).

Co się tyczy VM, nigdy nie miałem takich poważnych problemów jak to niektórzy raportuję. To nie znaczy, że nie ma problemu, chcę tylko wskazać, że nie jest to powszechne zjawisko. Dla zastosowañ intensywnie korzystających z VM, polecałbym jądro 2.2.19 jako pewien środek zaradczy i poczekałbym aż kod VM się ,,dotrze''. Takich narzekañ oczekiwałbym raczej w fazie -test, nie wspominając nawet o tym, że 2.4.x zostało włączone do dystrybucji.

Uwagi Linusa na temat 2.4.0 były raczej jasne i mówiły, że potrzeba conajmniej dwa razy tyle RAM-u co swapa w 2.4.

Marcelo pracuje nad zmianą tego stanu, ale obecnie używasz czegoś, czego brak działania został dokładnie wyjaśniony, a oczekujesz, że będzie jednak działać.