Kernel Traffic #183 For 2002/09/09

Ale to są dokładnie te rodzaje przypadków, w których opcje konfiguracyjne _nie_ działają dobrze.

Są tony powodów dla których chce się uruchamiać to samo jądro na wielu maszynach, nawet pomijając problemy takie jak instalatory itp.

Mieliśmy to chore CONFIG_xxxx gdy przyszło do SSE, mieliśmy to z TSC itp. I w każdym przypadku okazywało się, że to jest źle, po prostu dlatego, że to nie jest właściwy interfejs dla _użytkowników_.

Dlatego właśnie myślę, że kod równoważenia IRQ powinien tam być, niezależnie od wszystkiego, i być dynamicznie włączony wtedy, gdy jest potrzebny (albo wyłączany tam, gdzie przeszkadza, wszystko jedno). Ale _nie_ powinien być opcją konfiguracyjną.

mając na uwadze poprzednie próby włączenia ich pracy do głównego jądra, sądzimy, że w tym momencie oni naprawdę wolą być osobnym projektem i niewłączanie ich całej pracy do jądra im sprzyja.

USAGI może tylko zaakceptować ten komentarz, a jedyny sposób, w który mogą temu zaprzeczyć jest włączenie ich kodu do naszego jądra, o co są bez przerwy proszeni.

Moim zdaniem USAGI dostało więcej niż wystarczającą liczbę możliwości włączenia całej ich pracy do głównego jądra. Aleksiej Kuźniecow przez lata ciągle ich prosi o połączenie kodu i nigdy im się to nie udało. Czasem udaje się włączyć jedną albo dwie poprawki błędów, ale na tym kończą się wspólne wysiłki.

Zgłaszają, że bardzo by chcieli się połączyć, ale działają w zupełnie przeciwny sposób. To jest prawie haniebne i mam już dość tej publicznej propagandy, która sprawia, że wygląda na to, że to wina moja i Aleksieja.

Słowem kluczowym jest tu słowo ,,ty'', używasz go lokalnie, na swojej maszynie.

Nie istnieją szkieletowe rutery ipv6, wszyscy ciągle używają tuneli albo mają sieci zbudowane dla własnego użytku.

Uruchomiłem parę szybkich serii testów na małej maszynce. Intencją tego działania było zobaczenie, jakie liczby i jakie wnioski pokazuje VM Regress w najnowszej, publicznie dostępnej wersji. VM Regress to projekt będący początkiem narzędzia, którego podstawowym celem jest odpowiedź na pytania dotyczące VM przy pomocy testowania i porównywania poszczególnych części podsystemu. Zarysowane tu wnioski są wnioskami zupełnie ad-hoc, zatem nie traktowałbym ich zbyt poważnie.

Uruchomiono 4 testy na każdej maszynie, każdy odnosił się do anonimowej pamięci używanej w mmapowanym regionie. Zostały użyte dwa wzorce odwołań, smooth_sin i smooth_sin-random. Oba zbiory pokazują krzywę sinusoidalną, na której narysowano ile razy następuje odwołanie do każdej strony (patrz: zielona linia na rysunku stron w pamięci i wyrzuconych na dysk). Przy smooth_sin, odwołania do stron odbywają się po kolei. Przy smooth_sin-random, odwołania odbywają się w losowej kolejności, ale zachowywana jest liczba odwołań.

W trakcie testów obu schematów dokonywanych jest 2.000.000 odwołań do zmmapowanego regionu. Pierwszy region zawiera 25000 stron, ma w przybliżeniu taką wielkość, jak fizyczna pamięć maszyny. Drugi ma 50000. Niestety, niedostępne są szczegółowe informacje statystyczne, można jednak wyciągnąć jakieś wnioski. Dostarczanie informacji statystycznej jest w planach wersji 0.9.

Test 1 - smooth-sin_25000
http://www.csn.ul.ie/~mel/vmr/2.4.19/smooth_sin_25000/mapanon.html
http://www.csn.ul.ie/~mel/vmr/2.4.19-rmap14a/smooth_sin_25000/mapanon.html

Zachowanie jest dość porównywalne. Średni czas dostępu do strony wygląda mniej więcej tak samo, więc w końcu wydajność jest podobna. rmap14a działa lepiej, ale test nie trwał wystarczająco długo, żeby to potwierdzić. Podsumowując, gdy dostępne jest wystarczająco dużo fizycznej pamięci, rmap14a i ,,oficjalna'' pamięć mają mniej więcej tę samą wydajność przy liniowym odwoływaniu i pamięci nie brakuje.

Test 2 - smooth-sin-random_25000
http://www.csn.ul.ie/~mel/vmr/2.4.19/smooth_sin-random_25000/mapanon.html
http://www.csn.ul.ie/~mel/vmr/2.4.19-rmap14a/smooth_sin-random_25000/mapanon.html

tutaj średnia wydajność zostaje mniej więcej taka sama. Interesujące jest to, że rmap14a ma okresowo długi czas dostępu do stron. Mimo to rmap14a szybciej zakończył test. Znowu zatem, jeśli tylko nie brakuje pamięci, wydajność pozostaje mniej więcej taka sama, nawet przy relatywnie losowym wzorze odwoływania się do stron.

Test 3 - smooth_sin_50000
http://www.csn.ul.ie/~mel/vmr/2.4.19/smooth_sin_50000/mapanon.html
http://www.csn.ul.ie/~mel/vmr/2.4.19-rmap14a/smooth_sin_50000/mapanon.html

Ten test jest interesujący. Pamiętajcie, że odwołania są liniowe w pamięci. Przy około 1,000,000 odwołań do stron wyczerpuje się fizyczna pamięć. Oba testy skończyły się z takim samym czasem, zatem patrząc na ,,surową wydajność'' wydają się być takie same, ale tak nie jest. Wykres czasu dostępu pokazuje, że przez większość testu rmap14a dawał średnio lepsze wyniki, ale co pewien czas miał skoki. W końcu szybko to się zmniejsza, ale dostęp do strony jest ciągle szybszy niż w VM z oficjalnego jądra o około 300000 mikrosekund. Pokazuje to nieskalowany wykres.

http://www.csn.ul.ie/~mel/vmr/2.4.19/smooth_sin_50000/mapanon-time-unscaled.png
http://www.csn.ul.ie/~mel/vmr/2.4.19-rmap14a/smooth_sin_50000/mapanon-time-unscaled.png

To wydaje się zgodne z raportami mówiącymi, że dla normalnego jądra spada to powoli, poczas, gdy rmap wydaje się odbiegać bardzo szybko w niektórych sytuacjach.

Podejrzewa się, że duże, okresowe ,,zęby'' na wykresie pojawiają się wtedy, gdy znajdowana jest odpowiednia strona, ale to jest tylko zgadywanie a VM Regress nie znajduje się na tym etapie, na którym może być dokładniej wyśledzone.

Drugą rzeczą do zauważenia są obecne w pamięci strony na końcu testu. Normalne VM nie próbuje nawet trzymać pewnych stron w pamięci. Gdy pamięć fizyczna się kończy, to na dysk zrzucane są bezwarunkowo. rmap14a próbuje zatrzymać w pamięci odpowiednie strony, co pokazuje wykres odwołań do stron w stosunku do obecności stron w pamięci. normalne jądro ma duży blok stron w pamięci, rmap14a wyrzuciło z pamięci niektóre strony na początku testu.

W tym przypadku, VM z jądra udało się poprawnie wyrzucać strony, bo usuwane strony nie zamierzały być użyte w tym szczególnym przypadku.

Test 4 - smooth_sin-random
http://www.csn.ul.ie/~mel/vmr/2.4.19/smooth_sin-random_50000/mapanon.html
http://www.csn.ul.ie/~mel/vmr/2.4.19-rmap14a/smooth_sin-random_50000/mapanon.html

W tym teście porządek odwołań do strony jest losowy, więc określenie tego, którą stronę usunąć jest znacznie trudniejsze. rmap14a zakończył ten test prawie 10 minut wcześniej niż VM z normalnego jądra.

Średni czas dla VM z jądra jest ciągle zły. Podejrzewam, że tak się dzieje, bo jądro ciągle wyrzuca cały proces. rmap ma okresy szybkiego dostępu z, niestety, dużymi skokami, bo próbuje ono trzymać odpowiednie strony w pamięci, a ich znalezienie zabiera dużo czasu. Ta cecha powoduje, że takie rozwiązanie jest lepsze od tego z jądra, które nigdy nie ma właściwych stron w pamięci.

Wnioski

Trudno wyciągnąć słuszne wnioski, bo ciągle nie mamy pełnych danych, ale coś tam można powiedzieć. Jestem pewien, że doświadczony deweloper VM będzie umiał wyciągnąć wnioski, na których będzie można bardziej polegać :-)

Po pierwsze, jeśli dostępna jest wystarczająca ilość pamięci fizycznej, to rmap i VM z jądra zachowują się mniej więcej tak samo, nie jest wprowadzany żaden zauważalny narzut dla normalnego, anonimowego użycia pamięci.

Po drugie, gdy pamięć jest zapełniona, na całość wydajności odwołań wpłynie zachowanie pojedynczego typu odwołania. Przy dokładnie liniowym wzorze odwołań, vm z jądra będzie miał lepszą wydajność, bo po prostu naraz zrzuca wszystkie stare strony. Szczerze wątpię, że takie odwołania często się zdarzają.

Dla innych wzorów odwołań z dużym anonimowym użyciem stron, rmap ma większe szanse być bardziej wydajny, bo stara się trzymać anonimowe strony w pamięci. Nawet przy kompletnie losowych odwołaniach będzie miał sensowną wydajność.

W końcu, z testów w oczywisty sposób wynika, że przy decyzji, którą stronę przesunąć na partycję wymiany ważniejszy jest wiek tej strony, a nie częstość odwołań do niej, ale to już wiadomo. Wykresy wieku stron już są robione i będą dostępne w VM Regress 0.7.

Zamiast pisać pseudokod, podam odnośnik do funkcji generującej odwołania smooth_sin:

http://www.csn.ul.ie/~mel/vmr/smooth_sin.html

To jest naprawdę surowe i napisane do generacji każdego typu danych i tak będzie, dopóki nie znajdę czasu na generowanie bardziej realistycznych danych, co jest projektem samym w sobie. Każdy, kto chciałby wygenerować lepsze dane musi tylko wyedytować sobie plik References.pm.

Na wejściu bierze trzy rzeczy:

odwołania - liczbę odwołań do generacji zasięgu - rozmiar regionu w stronach dla wyjścia odwołań - nazwę pliku z wyjściem

funkcja ma trzy części:

część 1: Rysowanie sinusoidy takiej, żeby suma wszystkich wartości całkowitych każdej części wygenerowała wystarczająco dużo odwołań, żeby spełnić warunek mówiący, że ma być to conajmniej połowa żądanej liczby
część 2: Zaczynanie od początku zasięgu, odwołanie do każdej strony w porządku liniowym dopóki nie zostaną wygenerowane wszystkie pożądane odwołania
część 3: Zrzucenie na dysk wszystkich odwołań

teraz gdy o tym myślę, to bardziej sensowne byłoby najpierw zastosować liniowy wzór odwołań, a potem wygenerować krzywą sinusoidalną, ale wiedząc, że ten wzór w ogóle nie przypomnia niczego, co może zdarzyć się naprawdę, nie martwiłem się o to zbytnio. To pewnie coś, co powinienem zmienić, jako że to lepiej zilustrowałoby, które strony są trzymane w pamięci.

smooth_sin-random
http://www.csn.ul.ie/~mel/vmr/randomize_references.txt

To jest skrypt perlowy do losowego przekształcania pliku wejściowego. Na wejściu bierze plik wygenerowany przez funkcję smooth_sin, a na wyjściu daje plik z losowymi odwołaniami. Jest bardzo prościutki

1. Dla każdego odwołania na wejściu dostaje losową liczbę między 0 a zasięgiem a następnie odwołanie wejściowe
2. Sortuje plik numerycznie przy użyciu sort. To pozwala dać losowość wejścia
3. Tak przetworzone wejście jest czytane na nowo i usuwane są losowo wygenerowane elementy

Wpadłem na to, jak trochę pomyślałem i przerobiłem algorytm w 0.7. Żeby ułatwić całość, dodałem nowy wykres do raportów, który w 0.7 nazwałem ,,Indeks odwołań do stron w czasie''

patrz

http://www.csn.ul.ie/~mel/projects/vmregress/output_sample/mmap/read/25000/mapanon.html

To ten drugi wykres. Na początku jest on na zerowej stronie i przesuwa się po przestrzeni adresowej w czasie. Zupełnie losowy wzór spowodowałby, że wykres wyglądałby jak wykres szumu. Wykres ten powinien dać dobry obraz tego, jak odbywają się odwołania do pamięci.

W 0.6 przy tych testach, byłaby to podobna krzywa, z wyjątkiem tego, że do ostatniej strony odwołowanoby się około 40000 razy przez końcem testu. Oprócz tego, odwołania do stron odbywały się według wzorca liniowego, co było błędem znalezionym po przejrzeniu kodu.

Jeśli ktoś wciąż jest zainteresowany, uruchomię ponownie pełny zbiór testów na 2.4.19 i 2.4.19-rmap14a z 0.7 i ostateczne wyniki wraz z informacją o odwołaniach do stron, więc tym razem nie będziecie musieli zgadywać. Puszczenie całej serii zajmuje mniej więcej cały dzień. Ktoś chętny?

Opóźnione przez różne problemy (włączająć w to błąd MTRR występujący tylko przy HT, który Ingo w końcu znalazł, a który chodził za mną wiele dni). W rezultacie plik jest całkiem spory.

Najbardziej zauważalna jest (już dyskutowana) zmiana IDE i uaktualnienia wątków. Zmiany w warstwie wejścia mogą okazać się trochę bolesne przez chwilę, bo nie tylko dodano dużo opcji konfiguracyjnych, które trzeba dobrze ustawić, by mieć działającą klawiaturę i myszkę (poprawimy ten koszmar użyteczności), ale też same sterowniki są inne i bardziej podobne do urządzeń, które zależały od różnych przyzwyczajeń.

Został włączony główny kod AIO od Bena, Al pracował nad uporządkowaniem rzeczy związanych z gendisk dla wielu sterowników, co zostało ostatnio opuszczone. Do tego dochodzą jak zwykle aktualizacje USB..

A, i różne aktualizacje architektur (sparc64, ppc64, ia-64).

W porządku. Oto zawartość zbioru łat, łatki przyjdą w następnych listach (nie będą przesyłane na l-k)

1. przesunięcie rzeczy z ide_register_subdriver() (łączące napęd z wyskopoziomowym sterownikiem) do ide-probe.c, zatem pozostałe rzeczy mogą być bezpiecznie równolegle wołane z wejściem na innych napędach [Andre]
2. koniec wprowadzania ->reinit() - Jens opuścił MOD_DEC_USE_COUNT w paru wyjściach z ide-cd i zapomniał usunąć pętli z ide-floppy, ide-tape i ide-scsi ;-) (->reinit() jest ciałem pętli w róznych ->init(), które powinno być robione dla jednego napędu; w 2.5.32 ide-disk jest w porządku, ide-cd jest w porządku, pomijając mniejsze błędy, a reszta jest kopią ->init())
3. umieszczenie napędów na listach cyklicznych - per-driver dla tych napędów, które zostały użyte przez sterowniki wysokiego poziomu i ata_unused dla nieużywanych. Umieszczamy napędy na ata_unused na samym końcu ideprobe_init(), a potem przesuwa je na listy sterowników, gdy są używane.
4. przesunięcie sprawdzenia typu medium, ->driver_req itp. z ide_scan_devices() do ->reinit(). ide_scan_devices() straciło pierwsze dwa argumenty (później całkiem zniknie).
5. podwójne wołania ide_cdrom_init(), idedisk_init(), itp. zostały usunięte z ide_init_builtin_drivers() (oba były stamtąd wołane (to znaczy z ide_init()) a potem w module_init() dla wysokopoziomych sterowników).
6. pętle w ide_cdrom_init()/ide_cdrom_exit(), itp. są wyciągnięte odpowiednio do ide_register_module()/ide_unregister_module().
7. dodanie ->owner do ide_driver_t. MOD_INC_USE_COUNT/MOD_DEC_USE_COUNT usunięte z ->reinit(). ide_reinit_drive() zmieniło się w ,,wołanie ->reinit() dla wszystkich wysokopoziomowych sterowników, które zostały zarejestrowane zanim ktoś zażądał napędu'' (zamiast wariantu, który pojawił się w 2.5.32; ładniejsze i działa poprawnie dla sterowników w modułach).

8. Oto centralna część serii:

   • ide_reinit_drive() zamieniło się w ata_attach(). Powiedzmy, że jakaś bestia bierze sobie napęd, stara się go dostarczyć wyskopoziomowym sterownikom, a potem wrzuca go do ata_unused, jeśli nic cholernika nie chce. Innymi słowy, to jest to, co robiło ide_register_module(), ale dla pojedynczego napędu.
   • ideprobe_init() woła ata_attach() zamiast dodawać do ata_unused.
   • eliminacja ide_register_module(). Niektóre funkcje wołające już tego nie potrzebują, a niektóre wystąpienia (ide_replace_subdriver()) tak naprawdę chcą ata_attach(drive).
   • ide_scan_devices() zniknęło. Zostały dwie funkcje wołające. To ide_register_module() i ide_unregister_module(). W pierwszym przypadku zmieniono to na ,,umieść sterownik na liście, wyczyść ata_unused przesuwając ją na tymczasową listę i zawołaj ata_attach() dla wszystkich napędów na niej''. W drugim przypadku jest to ,,usuń sterownik z listy, zawołaj ->cleanup() i ata_attach() dla wszystkich napędów'' (->cleanup() porzuca napęd, ata_attach() daje pozostałym sterownikom znać o tym napędzie; jeśli nikt go nie chce, jest umieszczany na liście ata_unused).

9. ->init() dla wysokopoziomowych sterowników nie jest nigdy wołane (to co innego niż module_init(), gdy są inicjalizowane). Metoda została usunięta, a wszystkie instancje wyczyszczone.
10. zamiast robienia bałaganu w ide_module_t, kładziemy samo ide_driver_t na liście (cyklicznej) - lista ta jest używane tylko przez ide_module_t dla wysokopoziomowych sterowników. ide_register_module()/ide_unregister_module() bierze teraz ide_driver_t (którego nazwa zmieniła się na ide_register_driver()). /proc/ide/drivers zmieniło się, tak by używać tej listy cyklicznej, używa też seq_file zamiast dawnego domorosłego kodu.

11. kawałki z 2.5:

    • add_gendisk()/del_gendisk() przesunęło się do into ->reinit() i ->cleanup() ide-{disk,cd,floppy} - to znaczy do momentów, w których wysokopoziomowy sterownik żąda/oddaje napęd.
    • register_disk() też przsunięte do into ->reinit().
    • konsekwentnie, revalidate_drives() zniknęło (wykonywało jakieś pokręcone opóźnione ponowne odczytywanie tablic partycji; już niepotrzebne). Tak samo z ide_geninit().
    • zmiany zgodności z 2.5 w ->revalidate() i obsłudze BLKRRPART - to samo co dla wszystkich innych urządzeń blokowych.

Powodem, dla którego nie mogliśmy zrobić po prostu #11 i prosto tego zakończyć były nieprzyjazne wysokopoziomowe sterowniki, które uważały, że napędy grają fair, jak tylko zostały wysondowane. To jest *źle* - praca z interfejsem (lub związanymi interfejsami) nadal może być ,,niebezpieczna'' i w takim momencie każde normalne WE/WY jest Złą Rzeczą(tm). W wyniku tego, musieliśmy używać bardzo starych sposobów obsługi partycji, rejestrowania, itp.

Nowy wariant pozwala sondującemu kodowi decydować, kiedy bezpiecznie jest wprowadzać ,,w obieg'' napędy - żaden wysokopoziomowy sterownik nie zobaczy napędu zanim nie zostanie zawołane ata_attach(). To przesuwa wiedzę o kolejności między konfiguracją, a normalne WE/WY kodu sondującego, tam gdzie to powinno być. Sterowniki wyskopoziomowe już nie muszą o tym nic wiedzieć - gdy tylko dostaną napęd, to wykonywanie na nich WE/WY jest już bezpieczne.

Problemy z kolejnością konfiguracji różnych interfejsów itp. ciągle zostały tam gdzie były - to zupełnie inna historia i to jest problem poprawek w niskopoziomowych sterownikach. Co więcej, miejsce, w którym wołamy ata_attach() jest bardzo konserwatywne - wykonujemy _całą_ konfigurację interfejsów, a potem wołamy ata_attach() dla wszystiego, co uda się znaleźć. W końcu, kiedyś sterowniki niskopoziomowe powinny umieć zrobić coś takiego: ,,skonfiguruj naszą grupę interfejsów, potem zawołaj ata_attach() dla ich napędów'', ale to znowu jest inna historia, którą z przyjemnością zostawię ludkom, którzy poprawiają sterowniki niskopoziomowe. Wszystkie problemy z szeregowaniem sterowników wysokopoziomowych zostały zredukowane do jednej zasady: nie wołaj ata_attach() dla napędu, zanim nie będzie bezpieczne uzyskanie WE/WY dla niego.

Zbiór łatek nie naprawia wszystkich problemów z tym sterownikiem - kod, który wszedł do 2.5 pochodzi z 2.4.19 i kilka megabajtów zmian weszło od tamtego czasu do 2.4.20-ac. Jednakże te zmiany są głównie w sterownikach niskiego poziomu, więc ich przeniesienie nie powinno spowodować problemów. Zostawię tę radochę Jensowi, żeby to zrobił jak wróci.

Gotowe i przesłane AC do przejrzenia.

Joel Becker
Nick Bellinger
Alan Cox
Peter Denison
Jeff Garzik
Benjamin Herrensch
Roman Zippel
Alexander Viro

Inni pomogli dostarczając pomysłów.

Powinno działać dla wszystkich architektur z IDE, mogą pojawić się inne problemy powodujące błędy kompilacji, ale nie powinny być związane z IDE.

http://www.kernel.org/pub/linux/kernel/people/hedrick/ide-2.4.20/ide-2.4.20-pre4-ac2.patch.bz2
http://www.kernel.org/pub/linux/kernel/people/hedrick/ide-2.4.20/ide-2.4.20-pre4-ac2.patch.gz
http://www.linuxdiskcert.org/ide-2.4.20-pre4-ac2.patch.bz2

http://www.kernel.org/pub/linux/kernel/people/hedrick/ide-2.5.32/

To powinno coś dać wkrótce, bo przeglądam różne kawałki, które możnaby wziąć i dostać się jeszcze do 2.5 przed DNIEM OSTATECZNYM, który nastąpi w Halloween.

Odrzucone. Znalazłem kilka błędów, trochę dziwnych zmian, a niektóre pliki zostały przesunięte w ewidentnie złe miejsca. Pomieszane tam też jest wiele niezależnych zmian.

Andre, żeby to się udało, potrzebuję

• Jednej zmiany w jednej łatce (z przyczyną)
• Wyjaśnień co to robi

Na przykład, mam pliki, które przesunąłeś lub zmieniłeś; oglądanie tego w diff jest straszne. Mam wielkiego diffa z błędami w środku (np. gayle w ppc) i jestem pewien, że mogę część spokojnie usunąć.

Zacznijmy od przesuwania plików. Prześlij mi diffa dla Config/Makefile i listę plików, które należy przesunąć wraz z informacją gdzie przesunąć. Wydaje mi się, że gayle powinno być w m68k, a nie w ppc (w sumie to jestem tego pewien), CMD640 to PCI, dlaczego więc ten plik jest w ,,legacy''. Przez ,,legacy'' rozumiałem coś przed PCI, a nie ,,myślę, że to śmieć'' 8)

Stoi, cofam te przesunięcia.

Przerabiam wszystkie rzeczy do przesłania. Potem resztę.

Daj mi chwilkę na uporanie się z Twoimi prośbami, Viro próbuje się nauczyć jak być szalonym łataczem, a nie bombardować łatkami.

Poniżej załączam łatkę odnoszącą się do 2.5.31 w głównej linii, implementującą obsługę anycast dla IPv6. Ten kod był przesłany i zaakceptowany przez projekt USAGI zeszłej jesieni. Poniżej przedstawiam wysokopoziomowy opis tej implementacji:

1. API:

   Jakkolwiek RFC przyrównuje anycasting do zwykłego unicasting, to sądzę, że bardziej odpowiednie jest przywiązanie go bliżej poszczególnych aplikacji, więc wybrałem API podobne do multicastingu. Zatem, zamiast trwale przywiązywać adres anycast do komputera, poszczególne aplikacje, które używają anycastingu mogą przyłączyć się lub opuścić ,,grupy anycast'', a komputer będzie rozpoznawać adres anycast jako swój własny, gdy jedna lub więcej aplikacji dołączy do grupy.

   Zatem, na przykład ktoś używający anycastingu do wysoko wydajnego DNS może dodać przyłączenie do grupy anycast w serwerze i tak długo, jak działa serwer DNS, komputer będzie odpowiadał na adres anycast. Ale komputer nie będzie odpowiadać na anycasty gdy serwis, który ich używa nie jest dostępny, zatem zepsuta aplikacja na serwerze, która się skończyła, nie odgrodzi tego serwisu, jeśli tylko są inni działający członkowie grupy anycast na innych komputerach.

   Nie wiem czy to jest kontrowersyjne, czy nie -- dokumenty RFC są napisane bardziej z zewnętrznego punktu widzenia, ale wydają się implikować pewien model zgodny ze sposobem użycia ,,ifconfig'' do dodania adresów anycast. Wydaje mi się, że taki model nie pasuje do najlepszych użyć anycastingu, ale chciałbym dowiedzieć się, co o tym myślicie.

   Interfejs aplikacji umożliwiający przyłączenie się i opuszczenie grupy anycast zawiera 2 wołania setsockopt(): IPV6_JOIN_ANYCAST oraz IPV6_LEAVE_ANYCAST. Argumenty są takie same jak dla analogicznych operacji multicast. Jądro trzyma licznik odwołań członków grup; jeśli staje się zerem, adres anycast nie jest rozpoznawany jako adres lokalny. Gdy licznik jest różny od zera, komputer nasłuchuje na określonym węźle tego adresu, przesyła ogłoszenia w odpowiedzi na żądania (z override=0) i dostarcza wyższym warstwom pakietów przesłanych na adres typu anycast.

   Istnieje także opisany poniżej interfejs w jądrze, który jest używany na przykład przez IPv6 mobility.

2. Model bezpieczeństwa:

   w RFC 2373 napisano:

   ,,Adres anycast nie może być przypisany do komputera IPv6, to znaczy, że może być przypisany tylko do rutera IPv6.''

   Łatka pogwałca to zdanie w 1. specjalnym przypadku i wyjaśnię dlaczego.

   a) Komputer może mieć ograniczoną możliwość użycia anycast w celu zapobieżenia sytuacji, w której ruting do adresów anycast dla pojedynczego komputera jest rozłożony pomiędzy wiele sieci fizycznych. Wydaje mi się, że aplikacje na początku będą takimi, które nie będą działały na ruterach (wysokowydajne serwery (DNS, http itp.) i mobile IPv6) i te szczególne przypadki nie będą miały problemu z wymaganiami dotyczącymi uczestnictwa w systemie rutingu. Używają one adresów anycast z prefiksem częstym dla adresów unicast w systemie, zatem normalny ruting i tak prowadzi do właściwej sieci i nie ma żadnych zewnętrznych kar na system rutingu za używanie tego typu adresów anycast. Z tego powodu za dozwolone uważam adresy, które odpowiadają istniejącym prefiksom unicast, nawet na zwykłych komputerach.

   W końcu (z przyczyn bezpieczeństwa), musiałem zdecydować, czy anycast powinno wymagać uprawnień superużytkownika. Multicasting tego nie wymaga, ale oczywiście byłby problem z przekłamaniami, jeśli aplikacja przyłączyłaby się do adresu ,,anycast'', który tak naprawdę byłby adresem unicast na innym komputerze w tej samej sieci. Z drugiej strony, wygodnie by było zwykłym użytkownikom móc mieć pożytek z anycastingu, gdzie takie użycie nie łączy się ryzykiem bezpieczeństwa.

   Poniższy kod pozwala nieuprzywilejowanym użytkownikom przyłączanie się do grup anycast, które mają prefiksy (nie wymagają specjalnej propagacji) zgodne z istniejącymi adresami unicast, wymaga jednak roota (tak naprawdę ,,CAP_NET_ADMIN'') i rutera żeby mieć inny anycast (zupełnie niedozwolone na normalnych komputerach). Sądzę, że powinno się to rozszerzyć tak, by wymagało CAP_NET_ADMIN dla wszystkich anycastów (nawet tych pierwszych), które nie są dobrze znane (żeby zapobiec oszukanym adresom unicast).

3. Implementacja:

   Kod przechowuje listę używanych adresów anycast dla danego interfejsu. Jest on zmodyfikowaną wersją istniejącego kodu multicast z poprawionymi niektórymi rzeczami i operacjami na liście anycast, zamiast operacji na liście multicast. Ponieważ lista adresów anycast jest odseparowana od listy zwykłych adresów, to w ogólności adresy anycast nie będą wybierane jako adresy źródłowe ani dostępne w celu niewłaściwego użycia. Protokoły (takie jak ICMP ECHO), które odpowiadają za wymianę adresu źródłowego na docelowy mają oddzielne sprawdzanie anycastów i w takim przypadku ustawiają źródło na 0 - to pozwala IPv6 wybierać adresy źródłowe spoza zakresu.

   Kod zawiera interfejs setsockopt(), który pozwala łączyć i opuszczać grupy anycast, ale nie ma jeszcze zmian potrzebnych do tego, by działały z nim UDP i TCP. TCP jest problematyczne, bo mechanizm przeszukiwania PCB opiera się na adresie docelowym, co musi się zmienić -- powinno to już na początku być niedozwolone. UDP może działać ograniczone do INNADDR-ANY, ale nie zrobiłem jeszcze potrzebnych zmian. Prawdopodobnie użyję adresu anycast jako źródła, więc będę potrzebował modyfikacji podobnej do tej, którą zrobiłem z ICMP, ale powinno to dać się zrobić bezpośrednio. W końcu, myślę, że pożądana jest też możliwość przywiązywania się także do adresów anycast.

   Nasza pierwsza aplikacja to mobile IPv6, więc ta łatka nie zawiera żadnych zmian wyższej warstwy, które być może mogą być wymagane dla wsparcia wszystkich aplikacji.

   Do użycia wewnątrz jądra, aplikacje (takie jak mobile IPv6) mogą wołać funkcje join i drop dla adresów anycast i funkcję, która sprawdza, czy urządzenie jest w grupie anycast (jeśli dev == 0, sprawdza, czy jakieś urządzenie jest w tej grupie).

   Oto one (podobne do funkcji multicast):

   int ipv6_dev_ac_inc(struct net_device *dev, struct in6_addr *addr)
   - dodaje ,,addr'' jako adres anycast na ,,dev''
   int ipv6_dev_ac_dec(struct net_device *dev, struct in6_addr *addr)
   - usuwa ,,addr'' z użycia jako adres anycast na ,,dev''

   używają one liczników odwołań, zatem tylko pierwsze wołanie do ,,inc'' dla konkretnego adresu doda nowy adres i tylko wtedy, gdy wszystkie odwołania zostaną usunięte przez ,,dec'' adres zostanie usunięty jako lokalny adres.

   Funkcja:

   int ipv6_chk_acast_addr(struct net_device *dev, struct in6_addr *addr)

   zwraca ,,true'' jeśli ,,addr'' jest adresem anycast na ,,dev'', w przeciwnym wypadku zwraca ,,false''. Jeśli ,,dev'' wynosi 0, to przeszukiwane są wszystkie urządzenia.

   Te 3 funkcje dostarczają interfejsu wewnątrz jądra.

4. Uwagi:

   Sądzę, że ip6_addr_type() powinno sprawdzać *tylko* dobrze znane anycasty, ponieważ wydaje mi się niewłaściw,e żeby ta funkcja musiała przeszukiwać listy wiązane adresów anycast. Potrzebowałaby także argumentu ,,dev'' jeśli go nie ma, jako że adresy anycast, tak samo jak adresy mulitcast i unicast, w tej implementacji są przywiązane do konkretnych urządzeń. Użycie tych adresów na innych urządzeniach nie powinno zwracać typu ANYCAST, ale powinno to robić dla urządzenia, które ma adres anycast. Zatem w większości przypadków bardziej odpowiednie będzie ipv6_chk_acast_addr(), a nie ipv6_addr_type().

   ipv6_addr_type(), z włączonymi modyfikacjami dla zarezerwowanych adresów anycast, ciągle będzie użyteczne w przypadkach, w których wiadomo, że adres *zawsze* będzie adresem anycast (na przykład, zapobieżenie ustawieniu zarezerwowanych anycastów na normalne adresy przez ,,ifconfig''), ale dla kodu wysokiego poziomu, zwykle wymagane będzie sprawdzanie urządzeń. Zatem polecam zatrzymanie obu i używanie ipv6_chk_acast_addr() żeby dowiedzieć się, czy jest to skonfigurowany adres anycast, używanie ipv6_addr_type() żeby wiedzieć, czy adres jest zarezerwowany dla anycastu (skonfigurowany, czy nie).

   Oto, do czego służy ten kod.

5. Testowanie:

   Napisałem programy do przyłączania się i opuszczania grup anycast i sprawdziłem istnienie tych grup przez interfejs /proc/net (plik ,,anycast6''). Użyłem snifferów sieciowych do obserwacji kolejności odkrywania sąsiadów i sprawdzenia, czy bit override jest czyszczony i testowałem to z wieloma komputerami w grupie anycast ,,rozmawiający'' z niezmodyfikowaną maszyną, która pinguje adres anycast. Sprawdziłem też, że kod dobrze obsługuje ,,override=0'' (obsługuje).

   Dodatkowo, nasza grupa mobile IPv6 użyła tego kodu do przetestowania anycastingu w odkrywaniu adresów w Dynamic Home Agent z kilkoma różnymi topologiami i konfiguracjami.

   Wykonaliśmy testy na maszynie z jednym procesorem i dla jąder z SMP na wieloprocesorowych komputerach.

6. Do zrobienia:

   Myślę, że następne kroki obejmować będą pozbycie się części UDP, tak, żeby normalne aplikacje z przestrzeni użytkownika mogły w pełni używać anycastingu.

Nie jest tak, że się z tym nie zgadzam, tak żeby było jasne, ale to nie kłóci się z RFC, które oczywiście nie zawiera opisu API i nie specyfikuje żadnego interfejsu anycast.

Jednakowoż moim najważniejszym celem jest posiadanianie obsługi anycast z interfejsem wewnątrz jądra w 2.5 przed zamrożeniem kodu. :-) Do testowania użyłem API setsockopt() i zostawiłem to w łacie dla innych, żeby mogli zrobić to samo. Chociaż myślę, że to właściwe podejście, z przyczyn, które wymieniłem, wolałbym, żeby ten, być może kontrowersyjny, fragment został usunięty z łatki, niż żeby z jego powodu opóźnione zostało włączenie interfejsu wewnątrz jądra.

Jedyne obecnie użycie anycast, o którym wiem jest w IPv6 mobility, które potrzebuje interfejsu wewnątrz jądra. Interfejs poziomu użytkownika jest ważny dla przyszłych aplikacji, a interfejs setsockopt() z licznikiem odwołań nie znaczy, że nie możemy mieć także także interfejsu ip/ifoconfig dla stałych adresów anycast (wymagane adresy anycast w tej łatce są na przykład stałe). Zatem nie jest to, moim zdaniem, przywiązanie się do jednego wyboru, ale posiadanie (wkrótce) obsługi anycast w jądrze jest ważniejszym pierwszym krokiem.

Ta łatka implementuje obsługę Prefix List w IPv6. Powody stworzenia tej łatki to:

• zgodność z RFC (RFC 2461 - Neighbor Discovery, rozdział 5.1 i inne).
• Prefix List jest potrzebna do obsługi Mobile IPv6, gdy zostanie ona przesłana na kernel-list

Ten kod został przetestowany z IPv6, jak i z Mobile IPv6. Został też zintegrowany z jądrem USAGI.

Strona projektu: http://www.csn.ul.ie/~mel/projects/vmregress/
Pliki do pobrania: http://www.csn.ul.ie/~mel/projects/vmregress/vmregress-0.7.tar.gz

Oto czwarta wersja VM Regress, które jest zalążkiem narzędzia do testowania regresji i do porównywania VM w Linuksie. To ostatnia wersja na jakiś czas, jako że fundusze mojego Uniwersytetu stają się coraz mniejsze. Moje się skończą za parę miesięcy i muszę niestety zmienić priorytety. Mam nadzieję, że wrócę do pracy nad tym, gdy zabezpieczę sobie zewnętrzne fundusze, by móc pracować jedynie nad zarządzaniem pamięcią wirtualną ogólnie, a w Linuksie szczególnie.

Ta wersja ma przynajmniej jedną ważniejszą poprawkę błędu. Mógłby on zostać pokazany przez maszynę SMP, która wykonywałaby testy alloc lub błędów stron. Nie miałem żadnych zgłoszeń i samemu też tego nie dostałem, ale jestem całkiem pewien, że możnaby uzyskać zakleszczenie. Projekt kompiluje się teraz dobrze z jądrem 2.5.32, które jest pierwszym jądrem 2.5 od 2.5.28 z którym to się udało. Nie udało mi się przetestować tego z jądrem 2.5.x, ale nie ma powodu, dla którego miałoby nie działać. Jestem zainteresowanymi wszelkimi opowieściami na temat działania/niedziałania VM Regress z 2.5.x

Uruchamianie testów jest teraz znacznie łatwiejsze, są teraz skrypty perlowe, które uruchamiają każdy test i porównanie, produkują raporty, rysują wyniki vmstat itp. Załadują i odładują moduły niezbędne do uruchomienia testu. To redukuje trochę uciążliwą pracę związaną z przygotowaniem testu. Dostępne są także skrypty przeskalowujące wykresy w danym stosunku, zatem porównywanie vmów jest trochę łatwiejsze. Strony man i pomoc on-line jest udostępniona dla każdego z nich.

Moduł mmap będzie teraz uruchamiał testy porównawcze czytania lub pisania zarówno na mapowaniach anonimowych jak i mapowaniach plików. Wykonuje wykresy pokazujące wiek stron, liczniki odwołań, strony obecne w pamięci i wyrzucone na dysk, to, do których stron odwoływano się w czasie, wynik vmstat i trochę informacji na temat czasów. Nie ma ciągle analizy statystycznej, ale to jest praca na 0.9. Pliki z danymi są wszystkie zachowywane jako pliki .data, zatem dowolne narzędzie statystyczne może zaimportować pliki, w których pola oddzielono spacjami. Odnośniki do przykładowych testów znajdują się na stronie w sieci.

Jeśli wrócę do pracy nad tym, 0.8 będzie miało symulację serwera www, którą nakreślił kiedyś Rik Van Riel. Większość z tego, co potrzeba jest już zrobiona w module mmam używanym przez bench_mmap.pl.

Dokumentacja jest, w granicach rozsądku, aktualna i dostarczana z paczką. Jeśli ktoś ma jakieś sugestie, albo chce coś zgłosić, to proszę je przysyłać, a je dodam do listy DoZrobienia. Będę pracował nad tym co jakiś czas.

Pełna lista zmian w 0.7

Wersja 0.7

• Aktualizacja bench_mapanon.pl, żeby wykonywało testy czytania/pisania
• Adaptacja mapanon.o i zmiana na mmap.o, żeby mogło mapować deskryptory plików
• Adaptacja bench_mapanon.pl do bench_mmap.pl, by było ogólnym testem porównawczym mmap
• Testy porównawcze umią zachowywać dane próbkowe
• Time.pm eksportuje nowe funkcje
• mapanon.o zmienione na mmap.o, obsługuje pliki i pamięć anonimową
• Dodanie wykresu pokazującego wiek stron w zależności od tego, w jakiej pamięci są strony
• Dodanie wykresu pokazującego wzorce odwołań
• Dodanie replot.pl do łatwego ponownego wyrysowywania danych czasowych
• Poprawione prawa dostępu do testów alloc i fault
• Usunięcie głupiego zakleszczenia w modułach alloc i fault
• Różne aktualizacje bibliotek perlowych
• Kompiluje się teraz dla ostatnich jąder 2.5.x (nietestowane)
• Automatyczne ładowanie i odładowywanie modułów jądra

[+ oznacza rzeczy, które poszły do Marcelo, o rzeczy, które nie poszły, * rzeczy, które są włączone teraz do głównego jądra, a X te, które okazały się złe i wypadły z jądra, - oznacza rzeczy niepasujące do głównego drzewa]

Synchronizacja i zebranie głównych spraw. Rzeczy dotyczące IDE, które przysłał Andre jeszcze nie weszły - odesłane do kolejnego debugowania. Ciągle zalecana jest ostrożność w obchodzeniu się z IDE, a wiadomo, że ide-scsi wywala się.

Linux 2.4.20-pre5-ac1

        Łączenie z 2.4.20pre5
o       Poprawka kompilacji IDE                         (me)
o       Aktualizacja defconfig                          (Niels Jensen)
o       Różne poprawki ostrzeżeń kompilacji             (Niels Jensen)  
+       Usunięcie debugującego printk epad, które umknęło   (Moritz Barsnick) 
o       Poprawka budowania PPC dla pre4-ac              (Ben Herrenschmidt)
o       Poprawka zawieszania w Matrox DRM               (Jonny Strom)
o       Przeniesienie poprawek przy alokacji w LDT z 2.5  (Manfred Spraul)
+       Lp tidy i poziomy printk                (Lucas Correia Villa Real)
o       Łatka aktualizująca rozmiar regionu yenta       (Manfred Spraul)
+       Poprawka wycieku magistrali i2c dla acorn pcf8583   (Silvio Cesare)
+       Poprawka e100                                   (Linus Torvalds)
o       Kolejne aktualizacje i810 audio                 (Juergen Sawinski)
+       Porządne wyjście ver_linux przy gcc 3.x         (Steven Cole)
o       Poprawki ppp_generic do budowy na maszynach     (Bjorn Helgaas)
        z out* jako makrami 
o       aktualizacje pdc4030                            (Peter Denison)   
+       aktualizacje sterownika dźwięku Forte           (Martin Petersen)
o       poprawka błędu ID AMD7441 PCI 
o       Ograniczenie makr asm-ia64 io                   (Andreas Schwab)

To idzie od razu po rc1, bo zawiera wiele poprawek problemów z lokalnym bezpieczeństwem znalezionych przez Solar Designera i paru innych gości. Reszta rzeczy jest mniej ważna, w sumie to cała kolejka rzeczy oczekujących na wejście do 2.2.

Specjalne podziękowania dla ludzi z Openwall, którzy wykonali prawie całą pracę związaną z przenoszeniem kodu związanego z bezpieczeństwem z 2.4.x. To jest głównie ich aktualizacja jądra, nie moja.

2.2.22-rc2
o       Poprawka problemów z isofs po loopbacku         (Balazs Takacs)
o       Przeniesienie z 2.4 shutdown/reset SIGIO        (Julian Anastasov)
o       Poprawka zgłaszania błędów w przypadku OOM      (Julian Anastasov)
o       Lista opiekunów 2.2 w MAINTAINERS               (Keith Owens)
o       Ustawienie atime dla gniazd AF_UNIX             (Solar Designer)
o       Odnowienie konfiguracji startowania SPARC MD    (Tomas Szepe)
o       Wiele dalszych poprawek znaku/przepełnień       (Solar Designer)
o       Poprawka ov511 'vfree w przerwaniu'             (Mark McClelland)

Mam zamiar przesłać 8 łatek:

• 2.5.29-keyboard
• 2.5.29-pci
• 2.5.29-rdunzip
• 2.5.30-pcnet_cs
• 2.5.31-serport
• 2.5.32-bug
• 2.5.32-flags
• 2.5.32-smph

To są łatki, które znajdują się w drzewie ARM i wydaje mi się, że będą użyteczne dla innych; pozbierano w nich poprawki błędów i kompilacji. Wszystko powyższe nie weszło do 2.5.32.

Gdzie to możliwe, zostały przesłane opiekunom albo na adres trivial patch Rusty'ego. Jednakże, jeśli ludzie chcą wziąć którąś z tych łatek, włączyć ją do swoich drzew, a w końcu przesłać je Linusowi, to ja nie mam nic przeciwko.

Wszystkie łatki, które nie zostaną wzięte zostaną w pewnym momencie ponownie przysłane (teraz to jest gdzieś między 3 tygodnie a miesiąc).

Oto wyczyszczenie pci_ops, które dyskutowaliśmy w zeszłym tygodniu na lkml. Usunięto sporo kodu ze specyficznych dla architektur implementacji funkcji pci_*_config* i z rdzenia pci_hotplug (tak, kod pci_hotplug ciągle nie działa, pracuję nad tym, będzie następne...)

Te łatki zawierają poprawki prawie wszystkich fragmentów kodu zależnych od architektury. Mam pewną liczbę łatek, które prześlę bezpośrednio do opiekunów architektur; te łatki nie są włączone do drzewa bk.

Chciałbym podziękować Mattowi Dobsonowi oraz Hannie Linder za wykonanie dużej części tej pracy.

Ta seria zawiera także łatkę driverfs pci pool od Davida Brownella (tak długo jak robimy zmiany w pci...)

Do wzięcia z: http://linuxusb.bkbits.net/pci-2.5

Poniższy ChangeSet dla obecnego drzewa Linusa w BK dodaje do VFS jedną funkcję, fs/inode.c::ilookup().

Funkcja ta jest wymagana w NTFS podczas zapisu stron metadanych i-węzła przy użyciu ,,ścieżki brudnych stron'' z VM, jako że potrzebujemy wiedzieć, czy jest aktywny i-węzeł w icache, ale nie chcemy wołać iget(), bo jeśli i-węzeł nie jest aktywny, to nie ma potrzeby jego zapisu... - można zamiast tego przejść do następnego .. - jeśli jest aktywny i-węzeł, to muszę dostać strukturę inode celem wykonania blokowania, odpowiednego do wykonania zapisu.

Jeśli coś się Wam nie podoba w tej łacie, to proszę, dajcie mi znać co to jest, najlepiej z opisem tego, co byście chcieli w zamian, żebym mógł łatkę zmodyfikować...

Bez takiego przeszukiwania icache niemożliwe jest zapisanie i-węzłów przez ,,ścieżkę brudnych stron'' VM, przynajmniej ja nie widzę innej możliwości. - Jedyną alternatywą jaką widzę, jest powielenie całej icache tylko dla NTFS, tak, żeby można było wykonać wewnętrzenie przeszukiwania, ale sądzę, że to głupie, mając na uwadze, że VFS trzyma już cache i-węzłów...

Poniżej znajdziecie łatkę, która dodaje możliwość paniki jądra, jeśli zabraknie uchwytów plików (przez ustawienie /proc/sys/fs/file-max-panic na none-0). Jeśli połączy się to z reboot-on-panic, to ozancza to, że serwer ma szansę wyjść z sytuacji, w której wszystko wariuje. W łatce wołane jest show_state przed paniką, żeby logować co się dzieje - dodanie czegoś podobnego, co dałoby listę otwartych uchwytów plików byłoby sensowne.

Łatka ta jest do nałożenia na czyste 2.4.19 i była testowana na sparc64.

syscalltrack-0.74, dziesiąta wersja _alfa_ programu śledzącego wywołania jądra Linuksa jest już dostępna. syscalltrack obsługuje wersje jądra 2.4.x na architekturach i386 i UML. Wersje 2.5.x także powinny działać, ale nie były równie wyczerpująco testowane. Ze względu na problemy techniczne, jądra 2.2.x NIE są obsługiwane w tej wersji. Obecna wersja zawiera obsługę prawie wszystkich wołań systmowych - od ostatniej wersji dodano ich ponad 100.

• Co to jest syscalltrack?

  syscalltrack składa się z pary modułów jądra Linuksa i obsługuje środowisko trybu użtykownika, które umożliwia przechwytywanie, logowanie i podejmowania akcji w trakcie wołań systemowych, które spełniają kryteria definiowane przez użytkownika. syscalltrack może działać w ,,trybie pincetki'', w którym tylko bardzo szczególne operacje są śledzone, takie jak ,,śledź i loguj tylko próby usunięcia /etc/passwd'', albo w trybie zgodnym ze strace(1), w którym śledzone są wszystkie obsługiwane wołania systemowe. syscalltrack może robić rzeczy, których nie da zrobić przy użyciu mechanizmu ptrace, bo jego rdzeń działa w przestrzeni jądra.

• Skąd można go wziąć?

  Informacja na temat syscalltrack jest dostępna na stronie domowej projektu: http://syscalltrack.sourceforge.net, oraz w plikach projektu.

  Źródła najnowszej wersji można pobrać bezpośrednio z http://osdn.dl.sourceforge.net/sourceforge/syscalltrack/syscalltrack-0.73.tar.gz, albo z innych serwerów lustrzanych sourceforge'a.

• Brak deweloperów:

  Projekt syscalltrack poszukuje deweloperów, zarówno do przestrzeni jądra, jak i do przestrzeni użytkownika. Jeśli chcesz przyłączyć się do zabawy, to skontaktuj się z nami na liście hakerów syscalltrack (http://lists.sourceforge.net/lists/listinfo/syscalltrack-hackers).

• Licencja i BRAK gwarancji

  syscalltrack jest Wolnym Oprogramowaniem, licencjonowanym GNU General Public License (GPL) wersja 2. Biblioteka 'sct_ctrl_lib' jest na licencji GNU Lesser General Public License (LGPL).

  syscalltrack jest w stadium _alfa_ i BEZ gwarancji. Przepuszczamy go przez testy i normalnie uruchamiamy na naszych systemach, ale jeśli coś się zepsuje, to musisz sam mieć wszystkie kawałki.

• Sygnatura PGP

  Od teraz wszystkie wersje syscalltrack będą podpisane. Ta wersja jest podpisana moim kluczem publicznym pgp, który można pobrać z http://vipe.technion.ac.il/~mulix/pubkey.asc lub przez
  'gpg --keyserver wwwkeys.pgp.net --recv-keys 0xBFD537CB'

Miłego hakowania i śledzenia!

=======================================================================
Nowości w wersji 0.74, ,,Hyperactive Iguana''
-----------------------------------------------------------------------

• Dodano całe mnóstwo nowych wołań systemowych. syscalltrack obsługuje teraz prawie wszystkie wołania systemowe dostępne dla 2.4.x: vhangup, wait4, swapoff, sysinfo, fsync, readv, writev, fdatasync, msync, getpgid, fchdir, personality, bdflush, flock, setdomainname, newuname, modify_ldt, mprotect, sigprocmask, create_module, init_module, delete_module, get_kernel_syms, setfsuid16, setfsgid16, llseek, quotactl, sysfs, getdents, select, sysctl, mlock, mlockall, munlockall, munlockall, sched_setparam, sched_getapram, sched_setscheduler, sched_getscheduler, sched_yield, sched_get_priority_max, sched_get_priority_min, sched_rr_get_interval, nanosleep, mremap, setresuid16, getresuid16, query_module, poll, nfsservctl, setresgid16, getresgid16, prctl, rt_sigpending, rt_sigtimedwait, rt_sigqueueinfo, chown16, getcwd, sendfile,getrlimit, mmap2, stat64, lstat64, fstat64, lchown, getuid, getgid, geteuid, getegid, setreuid, setregid, getgroups, setgroups, fchown, setresuid, getresuid, setresgid, getresgid, chown, setgid, setfsuid, setfsgid, pivot_root, mincore, madvise, getdents64, fnctl64, gettid, tkill, sched_setaffinity, sched_getaffinity, sys_olduname sys_ustat, old_select, getitimer, setitimer, uname. pread, pwrite, truncate64, ftruncate64, readahead.
• Poprawka błędu, polegającego na tym, że nie wypisywalibyśmy poprawnie parametrów wołania, gdy są one wyNULLowane. Teraz wypisujemy <NULL>.
• Dodanie obsługi wołań systemowych z parametrami typu loff_t i long.
• Poprawki kilku błędów w sctrace.
• Poprawka kilku ważnych błędów w parserze plików z danymi wołań systemowych (używanym w sctrace(1) i sct_config(1)), która powodowała, że poprawne pliki konfiguracyjne nie były akceptowane. Dodanie znacznie lepszego zgłaszania błędów.
• Wiele innych poprawek błędów i wewnętrznego czyszczenia kodu.

Znowu sporo rzeczy; osobiście byłbym wdzięczy, gdyby ludzie, którzy naprawdę używają ch*go sterownika stacji dyskietek go przetestowali. Złamałem się i próbowałem to naprawić, jako że w 2.5.x jest to zepsute dłużej niż większości ludzi chce się pamiętać.

Nie mam nawet dyskietek, żeby to przetestować, sprawdziłem tylko, że mogę przeczytać dwie stare dyskietki z kopiami zapasowymi; jedna przeczytała się dobrze, a na drugiej udało się przeczytać 90%, co i tak było lepszym wynikiem niż oczekiwałem, bo obie dyskietki mają przynajmniej pięć lat. Nigdy nie miałem szczęścia do tych nie budzących zaufania 3.5" rzeczy, wolałbym mieć z nimi jak najmniej do czynienia.

W każdym razie, oprócz stacji dyskietek, w jądrze znalazły się organizacyjne poprawki IDE zrobione przez Ala, kolejne łączenie z Andrew i trochę rzeczy związanych z siecią (przesunięcie segmentacji TCP na karty sieciowe i początki obsługi SCTP).

I NTFS, JFS i oczywiście aktualizacje USB. A, i trochę rzeczy dotyczących wejścia klawiatury, które powinny naprawić błędy w przełączeniach wejścia.

Nowy sterownik NTFS 2.1.0(a) jest teraz dostępny dla jądra 2.4.19. W NTFS 2.1.0(a) zaimplementowano pierwsze kroki w kierunku obsługi nadpisywania plików.

Pełne i przyrostowe łatki są dostępne ze strony Linux NTFS:
http://linux-ntfs.sf.net/downloads.html
i ze strony projektu na Sourceforge (tam są także starsze łatki):
http://sf.net/project/showfiles.php?group_id=13956&release_id=107961

Jeśli używacie bitkeepera, możecie wyciągnąć NTFS 2.1.0a z naszego repozytorium bitkeeperowego (uwaga: jest ono oparte na obecnym drzewie Marcelo w bitkeeperze, czyli w tej chwili jest to 2.4.20-pre5, będzie się to zmieniało zgodnie ze zmianami w repozytorium Marcelo):
http://linux-ntfs.bkbits.net/ntfs-2.4

Obecny kod jest relatywnie dobrze przetestowany zarówno dla mmap(2), jak i dla write(2), w obydwu przypadkach zarówno przy użyciu istniejących aplikacji do losowego zapisu do plików jak i specjalnych programów wykonujących specjalizowane zapisy w celu sprawdzenia warunków brzegowych.

Ciągle jednak kod był uruchamiany jedynie na dwóch komputerach, więc bardzo proszę o robienie kopii zapasowych przy używaniu tej wersji NTFS. Jestem przekonany, że Wasze dane nie znikną, ale nie jestem skłonny tego gwarantować. Wstawiłem do pakietu odpowiednio bardzo przerażającą wiadomość, żeby narazie przestraszyć przypadkowych użytkowników...

Cechy NTFS 2.1.0(a)
=========================

Możliwość nadpisywania istniejących plików zarówno przez mmap(2) jak i write(2).

Możliwość zrobienia loopbacka na pliku NTFS i posiadania pełnego dostępu czytania/pisania do urządzenia loopback. Można na przykład stworzyć system plików Linuksa na urządzeniu loop i go zamontować.

To była najbardziej pożądana cecha, bo pozwala ona na instalację Linuksa na partycji NTFS przy użyciu sztuczki z loopback, to znaczy pod windowsami ktoś robi duży plik na NTFS, potem startuje Linuksa (z CD instalacyjnego, z dyskietki lub z czegokolwiek) a potem jako root wykonuje:

mount -t ntfs -o rw /dev/hda1 /mnt/ntfs
losetup /dev/loop0 /mnt/ntfs/some_dir/preprepared_large_file
mke2fs -j /dev/loop0
mount -t ext3 /dev/loop0 /mnt/new_root
mkdir old_root
<instalacja Linuksa na /mnt/new_root>
umount /mnt/new_root
losetup -d /dev/loop0
umount /mnt/ntfs

Od tej pory, można startować Linuksa i używając minimalnego ramdiska załadowanego na przykład przez dyskietkę, trzeba mieć tylko coś podobnego do poniższego:

mount -t ntfs -o rw /dev/hda1 /mnt/ntfs
mount -t ext3 -o loop /ntfs/some_dir/preprepared_large_file /mnt/new_root
cd /mnt/new_root
pivot_root . old_root
exec chroot . sh <dev/console >dev/console 2>&1
umount /old-root

[Zauważ, że prawdopodobnie nie będzie można odmontować /old-root, ale to nie szkodzi. To nikomu nie przeszkadza... Zawsze można to schować wewnątrz root/old_root albo czegoś takiego, więc użytkownicy tego nie zobaczą.]

Tak naprawdę nie próbowałem instalować Linuksa w ten sposób, ale Richard Russon (flatcap) przetestował te rzeczy z loopback/mke2fs/read-write i mu dobrze działało.

Ograniczenia możliwości nadpisywania w NTFS 2.1.0(a)
================================================

• Pliki rezydentne są tylko zapisywane w pamięci, to znaczy zapis do plików mniejszych niż 1kiB nie jest permanentny. Ostrzeżenia dotyczące tego efektu są pokazywane przy użyciu printk().
• Uzupełnianie dziur/niezainicjowanych obszarów nie jest jeszcze obsługiwane.
• Zmiana rozmiaru pliku nie jest zaimplementowana i w aktywny sposób śledzona i przerywana.

Proszę wszystkich, którzy wypróbowywują ten nowy kod o powiadomienie mnie, jak się sprawuje...

Najnowszy zbiór łatek MMU-less jest pod adresem:

http://www.uclinux.org/pub/uClinux/uClinux-2.5.x

Głównie zmiany dostosowawcze do 2.5.33. Sporo wyrzucania starego cli/sti (którego już nie ma).

Kod nieblokującego przeszukiwania cache ipv4 route można wyciągnąć z -

http://lse.bkbits.net/linux-2.5-rcu-rtcache

Przyspiesza on przeszukiwanie cache o około 30-50%, co zmierzony przy pomocy testu porównawczego zaproponowanego przez Dave'a.

http://marc.theaimsgroup.com/?l=linux-kernel&m=102258603404836&w=2

Całą dyskusję można przeczytać pod adresem: http://marc.theaimsgroup.com/?t=102258611100001&r=1&w=2

Zmiany w stosunku do drzewa Linusa to:

ChangeSet@1.500, 2002-09-02 12:34:24+05:30, dipankar@in.ibm.com
Implementacja nieblokującego przeszukiwania tras z cache ipv4 przy użyciu RCU.

ChangeSet@1.499, 2002-09-02 11:54:55+05:30, dipankar@in.ibm.com
Dodanie ,,lekkiej'' bariery dla czytania (read_barrier_depends()) dla czytania zależnego od danych. Także dodanie bardziej bezpośrednich wersji nazw takich jak read_barrier()/write_barrier().

ChangeSet@1.498, 2002-08-27 00:27:13+05:30, dipankar@in.ibm.com
Dodanie infrastruktury RCU opartej na rcu_poll w jądrach -aa z obsługą wywłaszczania i oddzielnych kolejek dla każdego procesora.

Następująca łatka dodaje do aktualnego drzewa BK (albo do 2.5.33) infrastrukturę Config/Makefile/Documentation dla XFS. Cały kod XFS jest zbyt duży, by go wysyłać jako łatkę na lkml, więc umieściłem tarballa pod adresem:

ftp://ftp.kernel.org/pub/linux/kernel/people/hch/xfs/xfs-2.5.33-20020903.tar.gz

oraz

ftp://ftp.kernel.org/pub/linux/kernel/people/hch/xfs/xfs-2.5.33-20020903.tar.bz2

który może być po prostu rozpakowany w głównym katalogu ze źródłami jądra. Łatka i rozpakowany tarball daje w pełni funkcjonalny sterownik systemu plików XMS, ale nie daje żadnych dodatkowych cech, które wymagałaby zmian VFS.

Ten kod XFS bardzo różni się od ostatniej oficjalnej wersji (XFS 1.1). Nazywając rzeczy po imieniu, używa on ogólnego WE/WY, usunięto z niego sporo nieużywanego kodu, który był potrzebny w systemie IRIX, ale w Linuksie jest zastąpiony przez sprawdzenia na poziomie VFS (na przykład sławne sprawdzenia zmian nazw).

Systemy na x86 cierpią na brak powiązania między tym, co BIOS uważa za dysk startowy, a tym, co Linux uważa za to, co BIOS uważa za dysk startowy BIOS Enhanced Disk Device Services (EDD) 3.0 dostarcza możliwości, żeby adapter dyskowy w BIOS-ie mógł powiedzieć systemowi operacyjnemu, co według niego jest dyskiem startowym. Chociaż ta cecha nie jest jeszcze zaimplementowana w wielu BIOS-ach (co oznacza, że nie należy w pełni ufać jej działaniu), przyszedł czas na to, żeby Linux otrzymał jej obsługę, tak, by był gotowy na moment, gdy BIOS-y z taką funkcjonalnością będą dostępne.

EDD działa dostarczając lokalizacji (np. PCI 02:01.0) szyny (PCI, PCI-X, ISA, InfiniBand, PCI Express czy HyperTransport) i informacji o lokalizacji (np. SCSI ID 5 LUN 0) interfejsu (ATAPI, ATA, SCSI, USB, 1394, FibreChannel, I2O, RAID, SATA) dla każdego urządzenia BIOS Int13. Poniższa łatka tworzy CONFIG_EDD, które, jeśli zostanie zdefiniowane, wykonuje wołania odzyskujące i zachowujące tę informację. Potem jest ona eksportowana (tak, kolejne /proc, będę szczęśliwy, jeśli będę mógł to zmienić na driverfs lub cokolwiek innego, jeśli będzie to miało sens) do /proc/edd/{bios-device-number}, w następujący sposób:

# ls /proc/edd/
80 81 82 83 84 85

# cat /proc/edd/80
host_bus_type: PCI 02:01.0 channel: 0
interface_type: SCSI id: 0 lun: 0

Warning: Spec violation. Key should be 0xBEDD, is 0xDDBE
Warning: Spec violation. Padding should be 0x20, is 0x00

# cat /proc/edd/81
host_bus_type: PCI 04:00.0 channel: 0
interface_type: SCSI id: 0 lun: 0

Warning: Spec violation. Device Path checksum invalid (0x4b should be 0x00).

W powyższym przypadku BIOS int13 device 80 (dysk startowy) wierzy, że jest na PCI 02:01.0, SCSI szyna 0, ID 0 LUN 0 (w takim przypadku jest to karta Adaptec 39160). Podobnie, urządzenie 81 wierzy, że jest na PCI 04:00.0, kanał 0, ID 0, LUN 0 (karta Dell PERC3/QC). W obu przypadkach producenci BIOS muszą zrobić trochę poprawek, więc ostrzegam, że działanie BIOS-u może nie odpowiadać specyfikacji.

Odpytywanie sterowników urządzeń jest możliwe w przestrzeni użytkownika (zarówno przez SCSI ioctl lub IDE /proc/ide/*/config), żeby porównać wyniki celem określenia, który dysk jest dyskiem startowym.

Zgłaszane jest conajwyżej 6 urządzeń BIOS, co wypełnia przestrzeń, która zostaje w empty_zero_page. Ogólnie, można się przejmować tylko urządzeniem 80h, chociaż dla oprogramowania RAID1 wiedza o tym, czym jest 81h może również być użyteczna.

Najważniejsze zmiany zaimplementowane w tej łatce:
arch/i386/boot/setup.S - wołania int13 trzymają wyniki w empty_zero_page
arch/i386/kernel/setup.c - kopiuje wyniki z empty_zero_page do lokalnego miejsca
arch/i386/kernel/edd.c - eksportuje wyniki przez /proc/edd/

Jeśli tego użyjecie, prześlijcie proszę raport sukcesu/porażki wraz z typem adaptera i wersjami BIOS na adres edd30@domsch.com. Trzymam ich spis pod adresem http://domsch.com/linux/edd30/results.html. Jeśli jądro skompilowane z CONFIG_EDD=m, proszę przyślijcie mi wynik 'modprobe edd debug=1' - to więcej mówi.

Poniższa łatka nakłada się na BK-current 2.5.x. Jest też dostępna w BitKeeperze pod adresem: http://mdomsch.bkbits.net/linux-2.5-edd

gcml2 jest (oprócz innych rzeczy) analizatorem składni języka Linux kconfig. Wersja 0.7.1 jest dostępna pod:

http://sourceforge.net/project/showfiles.php?group_id=18813&release_id=108721

oraz

http://www.alphalink.com.au/~gnb/gcml2/download.html

Jest to wersja gcml2 naprawiająca błędy. Dziękuję Randy'emu Dunlapowi, w szczególności za zgłoszenia błędów. Przyszłe ogłoszenia takich wersji będą pojawiały się tylko na liście kbuild-devel.

Oto krótka lista zmian.

• Poprawienie błędu pamięci, który pojawiał się, gdy węzeł był zwalniany, ale nie usuwany z tablicy mieszającej wszystkich węzłów.
• Błąd CONFIG_DECSTATION w przeniesieniu na mips uruchamiał błąd asercji; ten przypadek jest teraz obsługiwany bardziej ostrożnie.
• Dodano dwa nowe ostrzeżenia, pętlę warunkową i pętlę zależności.
• Lepsza obsługa przypadku, w którym define_bool zależy samo od siebie.
• Poprawka błędnego zachowania w przypadku nieudanego znalezienia pliku źródłowego, która kończyła się parsowaniem reszty reguły bazowej.
• Użycie nazwy symbolu jako domyślnej wartości ,,wyboru'' nie powoduje już błędu parsowania.
• Różne mniejsze błędy, wycieki pamięci, poprawki szybkości.

Ostatnia i najfajniejsza akutalizacja statusu jądra jest dostępna pod adresem: http://www.kernelnewbies.org/status/

W tym tygodniu warte zauważenie jest włączenie SCTP (Stream Control Transmission Protocol) w 2.5.33.

Najnowsza wersja strony ze stanem zgłaszanych problemów znajduje się pod adresem: http://members.cox.net/tmolina/kernprobs/status.html

Uwagi:

• Wolę, gdy listy dotyczące tych raportów są kierowane bezpośrednio do mnie, nie na listę. Komentarze do zgłoszonych problemów będą dodawane do odpowiedniego wątku dyskusji, chyba że ktoś wyraźnie zaznaczy, by tego nie robić. Jeśli przysyłacie mi komentarz, to proszę wysyłajcie kopię na listę.
• Zrobiono duży postęp w przenoszeniu kodu sterownika IDE z 2.4 do 2.5. Trochę ludzi wypróbowało 2.5.33 i nie nastąpiła katastrofa. Aktualizacje są wciąż dodawane do jąder -ac i jąder w bitkeeperze.
• Obsługa dyskietki w 2.5 jest obecnie na wpół zepsuta, na wpół naprawiona. Sterownik działa obecnie (znaczy w 2.5.33-bk) na systemach plików z 512 bajtowymi blokami (np. vfat/msdos), ale wywala się na systemach plików z innymi rozmiarami bloków, takimi jak ext2, minix itp. Aktualizacja: Parę poprawek w samym sterowniku i w wartwie bio poprawiło sytuację. Wymaga to więcej testowania i potwierdzenia, że poprawka została włączona.
• Obsługa wklejania __FUNCTION__ została wyrzucona z gcc. To spowodowało błędy kompilacji w paru miejscach. Definicje typu:
  #define func_enter() sx_dprintk (SX_DEBUG_FLOW, "sx: enter " __FUNCTION__ "\n")
  muszą być zmienione na coś takiego:
  #define func_enter() sx_dprintk (SX_DEBUG_FLOW, "sx: enter %s\n", __FUNCTION__)
• Pozycje zaznaczone jako ,,Brak dalszej dyskusji'' nie zyskały żadnego dodatkowego komentarza na liście przez jedną lub więcej wersji. Te pozycje zostaną zarchiwizowane aż do następnej wersji.

               Raport problemów jądrze 2.5, 4 września 
   Nazwa problemu			Stan               	Dyskusja
   schedule() z wyłączonymi irq 	otwarty			03 wrze 2002
   schedule i przerwanie          	Brak dalszej dyskusji 	2.5.31
   oops w JFS 	              		Brak dalszej dyskusji 	2.5.31
   oops przy odmontowywaniu         	Brak dalszej dyskusji 	2.5.31
   problem z usb                   	Brak dalszej dyskusji 	2.5.31
   BŁĄD pte.chain                   	Brak dalszej dyskusji 	2.5.31
   zepsute cciss                    	propozycja poprawki	2.5.31
   oops w qlogicisp                  	otwarty                 01 wrze 2002
   błąd w qlogic                    	Brak dalszej dyskusji 	2.5.31
   oops w kmap_atomic               	Brak dalszej dyskusji 	2.5.31
   problem ze swapem                    Brak dalszej dyskusji 	2.5.31
   oops w gpm.c                  	Brak dalszej dyskusji 	2.5.31
   błąd alokacji stron 	        	Brak dalszej dyskusji 	2.5.31
   oops w driverfs                  	Brak dalszej dyskusji 	2.5.31
   oops przy restarcie 2.5.32          	otwarty                 30 sie 2002
   oops przy umount ext2                otwarty                 30 sie 2002
   DEBUG_SLAB oops                	otwarty                 30 sie 2002
   problemy z 2.5.32-mm1           	otwarty                 30 sie 2002
   problem z programowym zawieszaniem  	otwarty                 30 sie 2002

W porządku. Mój oops w JFS, który był oopsem w tym samym stylu jak ten z 2.5, zniknął. Niestety nie udało mi się jeszcze stwirdzić jak spowodować, żeby moja zupełnie normalna klawiatura PS/2 zadziałała z obecnym jądrem 2.5.33. Powodem tego są dziwaczności opcji sterownika wejścia. Nie mogłem tego jeszcze przetestować.

Ale podejrzewam, że ten oops w JFS 2.5 powinien także zniknąć. Nie potrafię jasno stwierdzić, czy to było coś, co zostało naprawione w drzewie JFS, czy to moja aktualizacja gcc, to znaczy coś zostało naprawione w gcc i nie chcę tego testować.

Wiele z was znało pewnie dewelopera jądra Linuksa, Leonarda Zubkoffa (opiekuna BusLogic i DAC960, między innymi). Leonard zginął ostatnio w katastrofie helikoptera. Patrz http://www.ktva.com/Stories/0,1413,163%257E6883%257E834332,00.html. Leonard był jednym z najzdolniejszych ludzi jakich znałem i uważałem się za szczęściarza, że mogłem z nim pracować. Będziemy za nim tęsknić.