Kernel Traffic #178 For 2002/08/05

Hm, bo próbowałem jakoś mu wytłumaczyć marketing gdy pracowałem w IBM pod koniec 1998 roku? (za co chciałbym bardzo przeprosić całą społeczność. CHCIAŁEM dobrze...)

W porządku, czas się oczyścić. W tamtym czasie strona fsf w sieci miała całą sekcję pod tytułem ,,nie nazywaj systemu operacyjnego linux''. Napisałem więc do Stallmana, by zaprotestować. Linux był rozpoznawalną i umacniającą się marką systemu operacyjnego, podczas gdy projekt Gnu w szerszym środowisku postrzegano głównie jako producenta narzędzi, a nazwa ,,Hurd'' dla większości ludzi nic nie znaczyła (nie wiem, mogłaby być to gra, albo arkusz kalkulacyjny, albo wosk do podłóg). Walka skierowana przeciwko nazwie Linux była wyraźnie bezproduktywna z marketingowego punktu widzenia. Jeśli chcielibyśmy namawiać ludzi do używania ,,Linuksa'', to prawdopodobnie ci namawiani przynajmniej by on nim słyszeli. Mówienie ,,To nie jest Linux!'' spowodowałoby, że czuliby się zagubieni. Krucjata Stallmana skierowana przeciwko Linuksowi zmniejszała znaczenie jednego z większych dokonań wolnego oprogramowania.

POWODEM, dla którego on to robił, zgodnie z jego stroną w sieci, było to, że hurd zastąpi jądro Linux. Powiedziałem mu, że jeśli naprawdę chce traktować ,,Gnu Hurd'' jako następcę ,,Gnu Linux'', jak to napisano na jego stronie, to najpierw musi dołożyć GNU do Linuksa i posłużyć się skojarzeniem, takim jak ,,Nestle Cornflakes'', ,,Warka Strong'', albo ,,Turbo'' przed nazwą, które pozwoliło Borlandowi sprzedać różne typy kompilatorów jako jedną ich rodzinę (Turbo Basic, Turbo Pascal, Turbo C, Turbo C++. Albo Nestle Cornflakes, Warka Strong itp...)

Wymieniłem z nim trzy albo cztery listy i zgodził się, że przestanie zwalczać używanie słowa Linux, a w zamian będzie bardziej promował GNU i podkreśli ich osiągnięcia i zasługi dla Linuksa. Wtedy wydawało się, że to dobrze...

Chciałbym bardzo przeprosić całą społeczność. Zostałem zawalony pracą i zarzuciłem moją połowę tej rozmowy na miesiąc lub dwa, a wtedy cała sprawa z ,,GNU/Linux'' dostała się na nagłówki, to był dla mnie duży wstrząs. Zamieniło się to wszystko w strasznie osobistą rzecz, a marketingowy punkt widzenia, o który mi chodziło, został zaprzepaszczony; nie było żadnego produktu do promowania, oprócz samego Stallmana; strzeliłem do własnej bramki, efektywność pomysłu była żadna. W każdym razie napisałem do niego jeszcze raz i próbowałem jakoś przebrnąć przez niektóre problemy związane z jego pierwszym podejściem do marketingu, ale on akurat był zasypany listami i już przestał słuchać...

Byłem wtedy także wystarczająco naiwny, że nie zdawałem sobie sprawy, że nisza marketingowa, którą mu wskazałem, była już zapełniona przez dystrybucje: Red Hat Linux, Slackware Linux, itp. Ostatnią dystrybucją, której używałem w tamtej chwili było SLS :) Tak naprawdę to myślałem, że FSF próbuje wypuścić dystrybucję Linuksa. (W sumie to zajmowali się -- Debianem -- ale projekty się rozeszły i Debian odciął się od nich w kwestiach politycznych. (Sporo projektów wydaje się to robić...) Sądzę, że strona FSF była trochę przeterminowana, gdy próbowałem wrócić do Linuksa po długiej dygresji w postaci OS/2 i Javy. Jakkolwiek Debian wciąż jest w pewien sposób związany z FSF i jako taki jest jedyną dystrybucją Linuksa, która na tyle przejmuje się Stallmanem, że wstawiła sobie GNU/ do oficjalnej nazwy. I próbuje uruchomić Hurda. Tak naprawdę, to chyba właśnie strona debiana skierowała mnie wtedy z powrotem na gnu.org...)

Teraz już wiecie. Jeszcze raz chciałem bardzo przeprosić. Przynajmniej przestał mówić ludziom, żeby w ogóle nie używali słowa ,,Linux'' na określenie nazwy systemu operacyjnego...

Dynamiczne sondowanie jądra (Kernel Dynamic Probes

Dynamiczne sondowanie jądra (kprobes) zapewnia interfejs do umieszczania w jądrze sond i odpowiedniej obsługi tychże. Sonda jest automatycznym punktem przerwania (breakpoint) umieszczanym dynamicznie w wykonywanych (w przestrzeni jądra) modułach, bez konieczności wprowadzania zmian do źródeł. Sondy zostały pomyślane jako usługa od zaraz, gdzie wymaga się jak najmniejszej ingerencji w działanie systemu. Zalecamy je szczególnie w systemach produkcyjnych, gdzie interaktywne odpluskwiacze są niepożądane. kprobes są również przydatne w systemach rozwojowych i testowych. Podczas testów błędy można spowodować lub zasymulować za pomocą sondy. Podczas prac rozwojowych kod odpluskwiający (np. printk) można łatwo włączyć, bez konieczności rekompilowania testowanego modułu.

Dla każdego sondowania podany jest adres funkcji obsługującej zdarzenie. Funkcje obsługujące zdarzenia sondowania działają jako rozszerzenia systemowej obsługi przerwań i powinny tylko trochę zależeć, albo w ogóle nie zależeć, od systemu. Ze względu na taki projekt, sondowania mogą być wstawione nawet w nieprzyjazne środowiska -- kod z przerwaniami, wyłączenia i przełączenia kontekstu, czy kod dla SMP -- bez negatywnego wpływu na wydajność systemu.

Interfejsy kprobes

kprobes ma dwa interfejsy: register_probe i unregister_probe.

register_probe:

Rejestracja definiuje punkt umieszczenia sondy, który musi znajdować się na granicy instrukcji poprzedzającej jakikiekolwiek prefiksy powiązanych opkodów. Definiuje także trzy adresy wywołań dla modułu sondującego:

• adres zdarzenia, wywoływany gdy sondowana instrukcja ma zostać wykonana. Przy powrocie kprobes wykona sondowaną instrukcję w jednym kroku,
• adres funkcji obsługi po wykonaniu, wołany gdy skończy się pojedynczy krok,
• adres błędu, wywoływany, jeśli pojawi się wyjątek dla którejkolwiek intrukcji wewnątrz obsługi błędów, lub kiedy kprobes przechodzi sondowaną instrukcję.

register_probe przekazuje strukturę kprobe:

struct kprobe {
       u8 * addr;      /* umiejscowienie punktu sondy */
       spinlock_t lock;
       struct list_head list;
       unsigned long status;
       /* Wołane przed wykonaniem addr  */
       kprobe_pre_handler_t pre_handler;
       /* Wywoływane po wykonaniu adrr, chyba że... */
       kprobe_post_handler_t post_handler;
       /* ...wywoływane, jeśli wykonywany adrr powoduje błąd (np. błąd strony).
        * Zwraca 1, jeśli błąd dotyczy sondy, inaczej jądro go zobaczy. */
       kprobe_fault_handler_t fault_handler;
       u8 opcode;
};

adrr:
umiejscowienie punktu sondowania, który musi znajdować się na granicy instrukcji poprzedzającej jakikiekolwiek prefiksy powiązanych opkodów -- zagwarantuje to etykieta w C.

pre_handler:
funkcja wywoływana, gdy sondowana instrukcja ma zostać wykonana.

post_handler:
funkcja wywoływana w przypadku pomyślnego zakończenia wykonania sondowanej instrukcji.

fault_handler:
funkcja wywoływana, gdy pojawia się wyjątek związany z jakimkolwiek oprogramowaniem.

• gdy wykonywane wewnątrz probe_handler
• gdy przekracza się sondowaną instrukcję

Od użytkownika wymaga się utrzymania tej struktury w pamięci rezydentnej tak długo, jak długo sonda pozostaje aktywna. Niektóre z pól są wykorzystywane wewnętrznie przez kprobes i muszą zostać zainicjowane jako NULL lub ZERO. Pola, które użytkownik musi zainicjować to addr i pre_handler. Pola post_handler i fault_handler są opcjonalne.

unregister_probe:

unregister_probe również wymaga struktury kprobe. Użytkownik musi wyrejestrować wszystkie sondy zanim usunie moduł obsługi sond.

Rozszerzenia dynamicznych sond jądra

Dynamiczne sondowanie jądra wywodzi się z łaty pełnego Dynamicznego sondowania. W jej skład wchodzi mechanizm pozwalający sondom istnieć w przestrzeni jądra. Interpreter języka RPN, rozszerzenia punktów obserwacyjnych i sond w przestrzeni użytkownika, będących częścią pakietu dynamicznych sond, będą dostępne jako dodatki na stronie internetowej dynamicznych sond.

http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes/

Przeciwnie, kiedy Intel przeniósł lokalne APIC z osobnej kości do procesora, w okolicach P54C, okulawili cały mechanizm. Poprzednio lokalne APIC potrafiło zaakceptować i zamknąć dowolną liczbę przerwań, ponieważ zawierało trzyczęściowy wektor, który mógł przechowywać wszystkie niezbędne informacje o stanie. P54C (i późniejsze) miał dwie zapadki (latches) na poziom przerwania. Poziom był definiowany jako górne pół bajta wektora przerwania. Zatem P54C mógł zamknąć tylko dwa przerwania dla, powiedzmy, zakresu ISA IRQ 0x31-0x3F. Nie za dobrze, gdy pojawią się trzy przerwania 0x3X. Numer trzy nie zostanie złapany.

Intel dodał nowe błędy stanu do lokalnego APIC i protokół magistrali pozwalający _nie_ dostarczać przerwań z powodu limitu zapadek. W zajętym systemie z dużą liczbą przerwań zauważycie czasem kilka takich błędów dziennie. Nie można z tym nic zrobić, poza przetworzeniem wszystkiego. To jest bardziej ostrzeżenie, niż komunikat o błędzie.

Na naszej maszynie NUMA P6 odkryliśmy, że lokalne APIC zaczynało czasami wypluwać błędy przerwań. Analizator magistrali APIC nie pokazywał żadnych błędów. Po prostu wariowało i żadne próby poprawienia błędu nie dawały rezultatów. Nigdy nie wypracowaliśmy rozwiązania, ani nie otrzymaliśmy wystarczającego wyjaśnienia od Intela. Jedyną działającą metodą było wyłączenie przerwania błędów APIC.

Oczywiście, oczyszczona wersja łaty apic_state_dump nie robiłaby tego lub pozwalałaby wybrać opcję.

Oto czwarte podejście do łaty ,,naprawiającej'' sterownik stacji dyskietek, popsuty przez zmiany w sterownikach urządzeń blokowych w 2.5.13-2.5.19 i 2.5.28.

W 2.5.28 nastąpiła zmiana w fs/block_dev.c ustawiająca rozmiar urządzenia stacji dyskietek na 0, a to powoduje błędy ENOSPC podczas zapisu do urządzenia stacji dyskietek. Ta czwarta wersja łaty dodaje obejście powyższego problemu.

Częściowy dostęp do VFS _może_ teraz działać. Stworzyłem system plików ext2 na /dev/fd0 na jądrze 2.5.28 z nałożoną łatą i przeszedł test fsck zarówno na jądrze 2.5.28, jak i na 2.4.19rc3. Kiedy jednak próbowałem zainstalować na tej dyskietce lilo, jądro dało komunikat ,,błąd w warstwie bufora w buffer.c:403'', całość nie działa więc poprawnie.

Miłośnicy teorii spiskowych mogą zasugerować, że zaplanowałem to, kiedy przekonywałem Cię do podzielenia obowiązku między kilka osób. Hmmm... Wspaniale 8-)

Prawda jest taka, że pomimo istnienia opiekuna agpart i pojawiania się Jeffa na dri-devel raz na jakiś czas, w zasadzie niemal wszyscy w tym grzebali i to pies Jeffa, skoro ostatni tykał się kodu, nie musisz więc bać się, że ,,to Ty jesteś podejrzany'' 8-)

Oto krótkie podsumowanie projektu, którym trochę się bawiłem przez ostatnie kilka dni. Projekt ma na celu śledzenie powiadomień o problemach, oopsach, błędach itd. jądra rozwojowego. Mam nadzieję, że okaże się przydatny. Kilka uwag o projekcie:

• Nie mam zamiaru śledzić literówek i pomniejszych błędów składniowych. Chodzi mi raczej o rzeczy kalibru kłopotów z IDE, zepsutego flock i dziwnych błędów pamięci, będących pretekstem do dłuższych dyskusji, a nie jednolinijkowych poprawek. Raczej będę sam decydował, co zostanie uwzględnione, a co nie.
• Podczas dłuższych dyskusji planuję pomijać fragmenty, które uznam za niezwiązane z tematem. Jeśli ktokolwiek uzna mój wybór za problematyczny, proszę skontaktować się ze mną prywatnie.
• Dostałem komentarze, że powinienem po prostu wskazywać poprawki itd. w zarchwizowanych wątkach. Zastanawiałem się nad tym, ale wydaje mi się, że ładnie wyedytowana dyskusja będzie przydatniejsza. Staje się to oczywiste zwłaszcza tam, gdzie fala wiadomości podąża z punktu do punktu. W tym przypadku wycięcie nagłówków i nadmiernych atrybutów uprzyjemnia je dla oka.
• Sugerowano też, że po prostu duplikuję listy rzeczy do zrobienia i inne materiały. Być może. Jedno, co z tego wynikło, to to, że zacząłem o pewnych rzeczach myśleć więcej, niż robiłem to do tej pory.
• Aby utrzymać listę w czystości, zamierzam archwizować poprawione rzeczy, eksponując tylko te rzeczy, których jeszcze nie ,,zamknięto''. Możliwy status punktu to otwarty (dyskusja wciąż się toczy, nie osiągnięto porozumienia w sprawie dostępnego rozwiązania), zaproponowano poprawkę (łata jest w trakcie testów, dyskusja nad nią trwa), przetestowana poprawka (ogólnie się na nią zgodzono, włączone w zestawy łat głównych opiekunów - aa, ac, dj - i gotowe do włączenia), zamknięte, kiedy zostało włączone do głównego drzewa.

Łata, którą zamieszczam, przeznaczona jest dla jąder z serii 2.4, ale łatwo ją przenieść na 2.5, poza tym myślę, że rdzeń jest wystarczająco stabilny i pozwoli w przyszłości na elastyczniejszą obsługę modułów. Kiedy już uaktualnię do 2.5 i uaktualnię kilka architektur wyślę tę łatę oficjalnie, każdy odzew byłby więc teraz pożądany. (Łata nie wymaga nowych modutils, chociaż w nowej wersji można zapobiec powstawaniu obejść, z tym jednak można poczekać.)

Łata ta implementuje nowy interfejs modułów. Najważniejsza zmiana polega chyba na tym, że licznik użyć nie jest już częścią struktury modułu. Jeśli licznik jest wymagany przez kod modułu, moduł jest o niego proszony. Licznik nie musi być dokładny, jedynie wartość zwracana przez funkcje wyjściowe decyduje o usunięciu modułu. To oznacza również, że żadne struktury jądra nie muszą być zanieczyszczane wskaźnikami modułów, struktura modułu jest teraz w zasadzie jego wewnętrzną sprawą, żaden normalny moduł nie musi w niej mieszać. To także oznacza, że MOD_INC_USE_COUNT/MOD_DEC_USE_COUNT/MOD_IN_USE jest nareszcie ostatecznie przestarzały. Moduły teraz utrzymują swój własny licznik użycia, ale to mniej bolesne od wskaźnika modułu (popatrzcie na przykład systemu plików poniżej). W innych przypadkach taki licznik już istnieje, np. interfejs podobny do proc może użyć pola i_count z i-węzła (stop() odwiązuje pozycję, exit() sprawdzałoby, czy i_count ma wartość 1). Poniżej zmieniłem kod affs i fs, aby zademonstrować nowy interfejs. Moduł jest definiowany w następujący sposób:

DEFINE_MODULE
        .start =        start_affs_fs,
        .stop =         stop_affs_fs,
        .exit =         exit_affs_fs,
        .usecount =     usecount_affs_fs,
DEFINE_MODULE_END

Powyższe definiuje strukturę automatycznie rejestrowaną podczas inicjalizacji modułu. Struktura jest elastyczniejsza niż ileśtam fukncji. insmod musi wiedzieć o wszystkich tych funkcjach, a tymczasem powyższa struktura jest inicjalizowana, kiedy moduł jest podwiązywany. Łatwo dodać nowe pola, np. nowe sekcje poprawek łatwo dodać bez kłopotania insmod.

Z drugiej strony, stare interfejsy wciąż działają (nawet bezpośrednie wywołanie init_module()), usunięcie takich modułów jest niemożliwe.

Podstawowa różnica widoczna dla użytkownika to /proc/modules pokazujący również moduły wkompilowane w jądro. Taka zmiana wymaga drobnej modyfikacji kbuild, wymaga bowiem niepowtarzalnych nazw modułów. Wciąż nie jestem całkiem usatysfakcjonowany tą częścią rozwiązania, ale wyraźnie widać, co jest możliwe. Ważniejsze jest, że zmniejsza się różnica między wkompilowanymi i niewkompilowanymi w jądro modułami.

Trochę więcej nudnych szczegółów implementacji:

• usunąłem wywołanie systemowe get_kernel_syms, modutils już go nie potrzebuje, tylko klogd go wciąż używa, ale może bez niego żyć i powinno zostać uaktualnione.
• nowe makra mod_for_each_locked/mod_for_done_locked do iteracji po liście modułów.
• __MODULE_STRING zamieniono na __stringify
• BKL zastąpiono semaforem
• get_mod_name/put_mod_name zastąpiono getname/putname

Tak jakbym w ogóle zrobił cokolwiek dla 2.5. Nie zrobiłem. Ktoś inny wykonał przeniesienie aic7xxx do 2.5. Koniec pieśni. 8-)

Niestety, nie miałem wystarczająco dużo czasu, aby zająć się 2.5. Szczęśliwie opiekowałem się sterownikiem w 2.4 i zajmę się nim w 2.5, gdy przyjdzie na to pora.

Najważniejsza część zmian była już szeroko dyskutowana na liście i już publikowana na niej wraz z wieloma poprawkami (mam nadzieję, że włączyłem wszystkie), chodzi o usunięcie globalnej blokady irq. W perspektywie krótkoterminowej (słynne ostatnie słowa), niektóre konfiguracje SMP przestaną działać, ale naprawienie tego nie powinno być strasznie trudne.

Również wiele innych zmian -- jak zwykle aktualizacje USB, aktualizacje fbdev, aktualizacje m86k i ppc64, poprawka w IDE oraz synchronizacja z Alem. Warstwa obsługi portu szeregowego została ostro przetrząśnięta (blokada irq w pewien sposób to wymusiła, ale oczekiwano tego od wystarczająco dawna..)

Tak, wiele sterowników nie będzie się kompilowało przy włączonym SMP, bo potrzebują globalnej blokady (która jest usunięta). To obejmuje sterownik IDE cmd640 i sterownik portu równoległego (również wiele innych, ale sądzę, że te dwa są najpopularniejsze).

To wszystko powinno działać w ten sam sposób, jak to działało dotąd na UP, i przypuszczalnie zepsute sterowniki będą już niedługo przepisane tak, aby używać lokalnych blokad (w niektórych przypadkach globalna blokada irq może nie być w ogóle potrzebna).

Właściwie, to sposobem na emulowanie cli/sti nie jest ,,pokropienie'' blokad, w ogólności możesz to zrobić przy pomocy _jednej_ blokady na podsystem.

Zatem narzucającym się sposobem, aby zasymulować zachowanie cli/sti jest dodanie jednej blokady z aktywnym czekaniem, która jest używana tylko w tym podsystemie, następnie użycie tej blokady przy wejściu w przerwaniach w tym podsystemie i zdarzeniach zegarowych i we wszystkich miejscach, gdzie używaliśmy clt/sti.

To się nieco bardziej komplikuje, gdy trzeba zasymulować zagnieżdżanie cli/sti, bo nie możesz zagnieżdżać spinlocków, ale to nie jest żadna wyższa matematyka.

Oczywiście, zrobienie tego _dobrze_ (w odróżnieniu od zwykłego i bezpośredniego przetłumaczenia semantyki cli/sti) będzie wymagało znacznie więcej pracy. Ale nawet taka translacja wprost poprawia stan poprzedni, ponieważ różne systemy będą teraz niezależne i ponieważ łatwiej później podzielić jedną blokadę tak, jak to będzie akurat potrzebne.

Linus, Linus, jak możesz mówić coś tak naiwnego? Nie muszę Ci mówić, że jeden zadowolony użytkownik nie oznacza, że nikt nie będzie miał problemów.

Kilka osób zgłosiło całkowitą utratę systemów plików. Wiele więcej zgłosiło częściowe uszkodzenia systemu plików. Teraz i Ty zgłaszasz częściowe uszkodzenia systemu plików.

FUD? Strach? Tak, strach jest uzasadniony dla każdego, kto nie robi kopii zapasowych. Niepewność? Tak, gdy system plików jest ponownie uszkodzony, nie jest całkiem oczywiste, co to powoduje. Wątpliwości? Tak, wiele osób wątpi, czy może sobie pozwolić na uruchamianie 2.5.ostatnie.

Tego wieczora uruchomiłem waniliowe 2.5.29 i zostałem nagrodzony uszkodzeniem systemu plików. 91 plików w /lost+found. Nic wielkiego. Kilka wersji jądra temu było o trzy rzędy wielkości gorzej.

IDE? 2.4.17 i 2.5.27+Jens są przy zwykłym używaniu dla mnie stabilne. IRQ? całkiem możliwe. Moim trzecim kandydatem jest USB. Systemy bez USB są znacznie bardziej stabilne.

I TO jest część problemu. Nie wiem dlaczego, ale podsystem IDE budzi w ludziach najgorsze emocje.

To jest, tak przy okazji, powód, dla którego nie cierpię warstw pośrednich. Ludzie obwiniają je o wszystko, a naprawienie ich dla jednych konfiguracji powoduje, że nie działają inne.

Ech, ponieważ nie ma aktywnego opiekuna SCSI, to nie mam chyba wielkiego wyboru?

SCSI nie ma opiekuna od kilku lat. Obecnie trzy osoby pracują nad tym w pewnym stopniu (Doug Ledford, James Bottomley i Ty), ale nie dostaję łat na czas i najwyraźniej nikt inny też ich nie dostaje.

Kolejny przypadek: wczoraj debugowałem z Matthew Dharmem pewne problemy w USB storage, a on podesłał mi łatki na podsystem SCSI twierdząc, że na liście scsi były one uznane za prawidłowe już w maju.

Zgadnijcie co? Nie dostałem tych łatek od żadnej z trzech osób, które uważam za najbliższe bycia opiekunami.

Zatem Twoja skarga o treści ,,powinno iść przez opiekuna'' jest na gnat. Nie wahaj się wchodzić na trybunę, ale zanim to zrobisz, nie rzucaj kamieniami w szyby.

Zgadzam się, ale ciągle chcemy mieć kogoś, kto naprawdę stanie na wyskości zadania i prześle mi łatkę po przeglądzie kodu..

I tak, jeśli nie będzie to ktoś z ustalonych poruczników, to nałożenie takiej łaty na oficjalne jądro będzie zależało trochę bardziej od tego, ile będę miał czasu. Oczywiście, wolałbym żeby opiekun SCSI nie synchronizował swoich zmian bezpośrednio ze mną, ale z kimś, z kim pracuję - tak długo jak to będzie rozsądne pod względem czasu.

(Dobrą _nowiną_ jest to, że w tej chwili opieka nad SCSI aktualnie nie była potrzebna - większość pracy była spowodowana ogólnymi zmianami w warstwie blokowej, z którymi oczywiście świetnie poradził sobie Jens. Reszta polegała _głównie_ na aktualizowaniu poszczególnych sterowników do interfejsu PCI DMA (do tego różne jednolinijkowe poprawki do warstwy blokowej).

*przytakuję* Zarówno Jens jak i Doug byli nieocenieni w chwili, gdy pożyczyłem sobie trochę rzeczy z 2.4 (a potem zebrałem różne inne małe kawałki dotyczące SCSI z różnych miejsc). Przy braku większego zrozumienia w tym obszarze (i braku motywacji, by w tym głęboko grzebać -- nie mam nawet dysków/kontrolerów SCSI, oprócz jakiejś starożytnej cpqarray, która jest rzadko włączana), dokładanie różnych kawałków do tego podsystemu ze znaczącymi komentarzami było ciężką pracą i czasem niemożliwą bez dodatkowych wyjaśnień Jensa czy Douga.

Na całe szczęście Doug wykonał świetną pracę, odchwaszczając to, co włączyłem i umieszczając tam n razy wypróbowane i przetestowane kawałki.

Głosuję za oboma. Sądzę, że to co robi James jest taką pracą podstawową, co oznacza tu odciążenie całej zabawy z 'synchronizacją/przesyłaniem Linusowi' na jednego z innych i jest chyba dobrym pomysłem, o ile oni się temu nie sprzeciwiają.

Linus nie zabił ,,pomysłu istnienia opiekunów'', po prostu przeszedł do czterowarstwowej hierarchii, ze względu na potrzebę skalowalności.

Przedstawię tu infrastrukturę rozwijania systemu w moim rozumieniu. Wszyscy, którzy się nie zgadzają z moim punktem widzenia są proszeni o uwagi, w przeciwnym wypadku powinno się pojawić coś w rodzaju kolejnego pytania w FAQ albo uaktualnienie pliku Documentation/SubmittingChanges.

Deweloperzy przesyłają co mają opiekunom. Opiekunowe podsyłają to porucznikom. Porucznikowie przesyłają Linusowi. Każda z osób na każdym poziomie może brać różne rzeczy od wszystkich pod nimi jeśli tylko chce, ale tylko ludzie z warstwy TUŻ pod dostają jakieś wyjaśnienia co do tego, dlaczego łatka nie została zaakceptowana.

To znaczy, jeśli ktoś, kto nie jest porucznikiem, prześle łatkę Linusowi, a Linus ją zignoruje, to raczej nie ma wielkich szans na wyjaśnienia dlaczego tak się stało. Jeśli porucznik podpisze się pod łatką i przekaże ją Linusowi, to jeśli ten ją odrzuci, to prawdopodobnie powie dlaczego tak zrobił. (Może się okazać, że skrzynka pocztowa się przepełni, ale problem ,,przesłałem to tuzin razy i nigdy nie dostałem odpowiedzi'' nie powinien dotyczyć sytuacji, w której łaty przesyłają porucznicy. W każdym razie w idealnym świecie. :)

To jest, tak ogólnie, to co jest najważniejsze w instytucji poruczników. Są JEDYNYMI ludźmi, którym Linus jest winien jakiekolwiek wyjaśnienia, gdy odrzuca łatkę. (Wyjaśnienie może zawierać tylko tekst ,,Nie podoba mi się to, nie zastosuję tego'', ale przynajmniej łatki te nie są bez końca w zawieszeniu. W najgorszym wypadku pomoże to zamknąć sprawę.)

Podobnie, porucznicy powinni odpowiadać opiekunom i zgłaszać im każdy przypadek odrzucenia łatek wysłanych przez opiekuna. A opiekunowie pownni odpowiadać poszczególnym deweloperom, którzy przysyłają im łatki (pocztą elektroniczną bezpośrednio, przesyłek na listę można nie zauważyć). Te odpowiedzi nie są tylko zwykłą kurtuazją, ale wspomagają działanie całego systemu.

Zatem jeśli dowolny deweloper chce, by jego łatka dostała się do Linusa, a Linus po prostu nie usłyszy jej w eterze, to sposób, w który należy postąpić polega na znalezieniu odpowiedniego opiekuna i uzyskaniu jego opinii na temat danej łatki. Deweloper powinien pracować z opiekunem, aż łatka zostanie zaakceptowana przez danego opiekuna: muszą oni naprawić wszystko, co nie będzie się podobało opiekunowi, a jeśli opiekun powie, że całość jest kiepskim pomysłem, to próby ,,przerzucenia nad jego głową'' do porucznika nie powinny dać pozytywnego skutku. (Mają świetną wymówkę, która pozwala im Cię ignorować, która jest dla nich rozwiązaniem wymagającym wysiłku. Teraz nie wolno im zawracać głowy, skończysz tak, że listy od Ciebie będą automatycznie usuwane.)

Opiekun może chcieć zmian, może uznać, że potrzebny jest przegląd kodu na specyficznej liście (czasem na linux-kernel, czasem nie), może chcieć zobaczyć wyniki porównawcze, może zażądać byś ściągnął i uruchomił narzędzie do testowania przy odpowiednim obciążeniu... Ale może też być zadowolony tak po prostu, albo może sprzeciwić się całemu pomysłowi i będziesz musiał zmienić całe podejście.

Zatem, kiedy tylko opiekun podpisze się pod łatką (,,dla mnie wygląda dobrze''), deweloper i/lub opiekun mogą przesłać ją do odpowiedniego porucznika, który odpowiada za większą część jądra i ma szansę znaleźć nowy zestaw rzeczy, które są źle w łacie i w ten sposób proces powtarza się na kolejnym poziomie. (Wiedza, do którego porucznika przekierować deweloperów z łatkami jest częścią pracy opiekuna.) Kiedy deweloper ubiega się o błogosławieństwo porucznika, to cały czas jego problemem są poprawki. Opiekun przekazuje tylko własne zdanie na temat łatki, a w dalszej kolejności robi to porucznik. Żaden z nich nie jest zobowiązany do wykonywania pracy za Ciebie. Znajdują problemy, ale sprawą dewelopera jest ich poprawianie. Twój pomysł ma szansę wzbudzić ich entuzjazm i z tego powodu mogą się nim zająć, ale nie ma na to gwarancji, zwykle mają listę rzeczy do zrobienia tak długą, jak twoje ramię (napisaną bardzo małą czcionką) i są to rzeczy, które będą robić, zanim twoja łatka wejdzie na tapetę.

Znowu, porucznik może zgłosić weto całemu pomysłowi łatki (akceptacja opiekuna nie oznacza akceptacji porucznika), albo zgłosić jakieś zastrzeżenia. Zaaprobowanie przez porucznika jest niezbędne dla dalszej kariery łatki, więc deweloper musi poprawić wszystko, co porucznik uzna za niewłaściwe, nie patrząc na to, co pomyślał opiekun.

Wtedy, gdy porucznik będzie zadowolony i podpisze się pod łatką, wędruje ona do Linusa. Porucznik pewnie będzie tą osobą, która przekaże ją Linusowi (umieszczając dewelopera w cc:), w przeciwnym wypadku Linus by jej nie zauważył (przeleciałaby przez jego skrzynkę).

Prościutkie, oczywiste poprawki błędów, mogą czasem przejść przy użyciu menedżera trywialnych łatek (coś takiego jak trivial@rustcorp.com, zajmuje się tym Rusty Russel, można przejrzeć archiwa.). Myślcie o nim jako o ,,młodszym poruczniku'', akceptuje łatki prosto od deweloperów, ale tylko takie, które naprawdę są oczywistymi poprawkami błędów.

Bitkeeper trochę tu pomaga: widać kiedy łaty idą dalej, więc można szybciej mieć informację zwrotną. I kiedy łatka jest w czyimś drzewie bitkeepera, może się przenieść wyżej bez wielkiej aktywności ze strony dewelopera (przynajmniej dopóki nic złego nie zostanie w niej znalezione). Ale żeby dostać negatywną odpowiedź (to znaczy, że ktoś to obejrzał i odrzucił i wyjaśnienia), deweloper wciąż musi przejść opisanym kanałem.

Zysk z tego jest dwojaki:

1. Deweloperzy nie trwają bez końca w zawieszeniu, gdy nikt nie odpowiada na ich listy zawierające łatki. W każdym momencie wiesz, kogo dręczyć o odpowiedź. (Może nie odpowiedź, której oczekujesz, ale jednak odpowiedź.) W ten sposób zostaje oszczędzony czas i nerwy deweloperów.
2. Zanim łatka dotrze do Linusa, jest już przejrzana przez dwóch kompetentych deweloperów (kogoś, komu bezpośrednio ufa i kogoś, komu ufa ktoś inny), oczywiste poprawki są już wykonane, a jeśli tych dwóch uznało, że łatka wymagała szerszego przejrzenia kodu, to zostało ono zasugerowane przed akceptacją łatki. (Niektórzy z nich mają własne drzewa jądra w celach testowych.) To oszczędza sporo czasu Linusa i jego nerwów. (A on ciągle będzie odrzucał wiele z tych łat. Albo wymagał zmian, tak jak będzie się działo na pierwszych dwóch poziomach.)

Powodem, dla którego niektórzy ludzie myślą, że opiekunowie nie mają teraz żadnego znaczenia jest to, że Linus nie odpowiada bezpośrednio opiekunom. Ponieważ Linus styka się z porucznikami, a porucznicy z opiekunami, którzy są pod nimi, Linus może nawet nic nie usłyszeć o niektórych opiekunach i zaufać ocenie poruczników. Opiekunowie są jednak potrzebni do tego, by skontaktować różnych nieznanych deweloperów z porucznikami, dzięki temu porucznicy nie są przeciążeni. Tak długo jak porucznicy słuchają swoich opiekunów, a Linus słucha poruczników, system dobrze działa.

Podsyłam wersję Alanowej ,,restrykcyjnej alokacji pamięci'' dla jądra 2.5, której zachowanie wspólnie z nim przedyskutowałem.

Dodaje ona restrykcyjną rejestrację dla wymuszenia limitów przestrzeni adresowej i tym samym wyeliminowania OOM. Wszystkie błędy przydzielania pamięci powinny być przeniesione do procedur alokacji.

Oczywiście ten typ alokacji jest preferowany przez większość, więc domyślnie włączone jest standardowe zachowanie. Restrykcyjna alokacja jest kontrolowana przez sysctl.

Chciałbym przenieść to zachowanie do 2.5, aby lepiej je przetestować oraz uzyskać podstawę dla poprawek 'shmem/restrykcyjnej alokacji', nad którymi pracował Hugh Dickins. Przy domyślnej konfiguracji, zachowanie nie powinno się zmienić.

Łatka jest przeznaczona dla 2.5.28, do dzieła.

Rozmyślałem trochę nad pewną ideą i chciałbym ją przedstawić do publicznej dyskusji, aby każdy mógł nad nią pomyśleć...

W czasach libc4/libc5 próbowano używać plików nagłówkowych jądra w przestrzeni użytkownika. Powodowało to totalny bałagan, nawet z tego powodu, że pliki nagłówkowe jądra dołączały tony kolejnych, a struktury danych były nieprzystosowane do użycia w przestrzeni użytkownika.

W bibliotece glibc oficjalnym stanowiskiem jest zasada ,,nie używaj plików nagłówkowych jądra''. To powoduje problemy, ponieważ niektóre rodzaje ABI jądra są dostępne jedynie przez pliki nagłówkowe, a ich ręczna reprodukcja jest czasochłonna i narażona na powstawanie nowych błędów.

Jestem w trakcie pisania mojej małej libc dla initramfs i będę musiał zmierzyć się z problemem użycia ABI jądra.

Wydaje się, że rozsądnym rozwiązaniem dojścia do tego nie jest używanie nagłówków jądra przez programy przestrzeni użytkownika, lecz dzielenie przez przestrzeń jądra i przestrzeń procesu małego zestawu plików opisujących ABI. Te pliki powinny być wysoko specjalizowane, aby opisywały tylko rzeczy widoczne dla przestrzeni użytkownika. Co więcej, jeżeli wprowadzają nowe typy zmiennych, niech używają wtedy ustandaryzowanego nazewnictwa, takiego jak w __jądrze__ systemu. Mogłyby być także użyte __s* i __u* dla określonych typów.

To oznacza, że moglibyśmy się pozbyć #if(n)def __KERNEL__ z głównych plików nagłówkowych jądra, a to z powodu separacji spowodowanej położeniem tychże plików -- część plików nagłówkowych jądra mogłaby zostać włączona do plików opisujących ABI, odwrotna sytuacja nie powinna nigdy zaistnieć.

Chciałbym zaproponować, by te pliki zostały umieszczone w przestrzeni plików nagłówkowych w <linux/abi/*> oraz <linux/abi/arch/*> dla plików zależnych od architektury sprzętowej (mimo tego, myślę, że te pliki powinny być umieszczone w drzewie linux/abi. Mógłoby tam istnieć dowiązanie symboliczne do ../asm/abi dopóki nie zmienimy całego układu plików nagłówkowych jądra.) Drzewo plików nagłówkowych linux/ powinno być przeznaczone, w przeciwieństwie do drzewa abi/, tylko dla jądra systemu. Nie odkryłem żadnych potencjalnych konfliktów. Całość miała się nazywać kabi, lecz wydaje się ,,czystszym'' użycie istniejącej przestrzeni nazw.

Jeżeli ludzie powiedzą, że to jest jakiś pomysł, wtedy spróbuję stworzyć całą infrastrukturę w ramach moich prac nad klibc. Z drugiej strony samodzielnie nie podołam przeniesieniu wszystkich potrzebnych plików nagłówkowych.

Cóż, początkowy zapał opadł i nic więcej się nie dzieje.

Czy jest jakakolwiek potrzeba aby zająć się tą kwestią?

Przypominam, że następna większa konferencja odbędzie się podczas Linux Kongress (Kolonia), na początku sierpnia. Może moglibyśmy tam zebrać ludzi od glibc/innych-bibliotek i dzięki nim zrobić pewien postęp.

Jeżeli będzie jakiekolwiek zainteresowanie (preferowany kontakt poza tą listą), to spróbuję skontaktować się z organizatorami i zaangażować w to BoF-a.

Zainteresuję się linux.conf.au jako dodatkową okazją, ale to dopiero w odpowiednim czasie.

Wysłałem Marcelo łatę LVM 1.0.5, która naprawia:

• błędy OBO dostępu do tablicy vg
• poprawki blokowania SMP
• użycie blk_ioctl()
• wcięcia

Jest dostępna pod: <http://people.sistina.com/~mauelshagen/lvm_patches/lvm_1.0.5+_25.07.2002.patch>

To jest w gruncie rzeczy ten sam sterownik, który podsyłałem poprzednio 3 razy, tyle, że z nałożonymi trzema łatami naprawiającymi błędy. Działa on z i386 (powinien pracować też z alphą).

Łatka nr 1 jest obecną wersją sterownika (z zaaplikowanymi inicjalizatorami zgodnymi ze stylem C99, obecną drzewie CVS m68k). Potrzebowała ona zmian, by w ogóle się kompilować. Pytałem poprzednio społeczność m68k, czy mają jakieś zastrzeżenia co do przesłanych im danych, lecz uzyskałem akceptację Richard Zidlicky'ego (który jest wspomniany na początku pliku) oraz Geerta Uytterhoevena.

Łata nr 2 jest wersją dla architektury PPC. Tworzy ona include/asm-ppc/rtc.h i znajduje się w drzewie bitkeepera dla architektury PPC już od ponad miesiąca. Mogę nakłonić Paula Mackerrasa by Wam to wysłał, jeżeli tylko wyrazicie ochotę.

Łata nr 3 jest moim dziełem. Zmienia ona set_rtc_time(struct *rtc_time) by zwracała ona int zamiast typu void. Została zrobiona w sposób, który umożliwia dodanie kodu zależnego od architektury, który wykona dodatkowe testy i zwróci ewentualny błąd. Wprowadza także include/asm-generic/rtc.h, include/asm-i386/rtc.h oraz include/asm-alpha/rtc.h. include/asm-generic/rtc.h zawiera funkcjonalność get_rtc_time and set_rtc_time pochodzących z drivers/char/rtc.c. Łatka została przetestowana na SMP i386. Zmodyfikowała też include/asm-ppc/rtc.h w celu zwracania -ENODEV w przypadku braku obecności zegara czasu rzeczywistego.

A teraz trochę o historii tego sterownika.

Kod znajdował się w drzewie m68k przez wiele lat, więc ogólny kod stojący za tym jest całkiem poprawny. Wyjęto z tego tyle, żeby dojść do punktu, w którym całość działała na innych architekturach (głównie ze względu na hybrydowe maszyny m68k/PPC). To jest całkiem użyteczne, odkąd pewna liczba architektur nie może używać drivers/char/rtc.c, ponieważ odbiegają one od siebie sprzętowo w znaczny sposób oraz jeszcze z innych względów.

To powinno być także użyteczne dla architektury MIPS, dla której kiedyś w przeszłości skopiowano kod RTC ze sterownika architektury PPC (drivers/macintosh/rtc.c) oraz użyteczne również dla innych maszyn.

W oparciu o pewne prywatne zgłoszenia, ludzie od parisc używali wersji 2.4 sterownika przez pewien okres czasu, więc przeniesienie tego na 2.5 powinno być dla nich trywialne (znajduje się to obecnie w ich drzewie, nieprzetestowane, co z pewnych względów powinno być najpierw rozwiązane). Wierzę, że z pewnymi dodatkowymi rozszerzeniami ia64 będzie również mogło z tego skorzystać. A kiedy ludzie od MIPS przekształcą swój sterownik czasu rzeczywistego ma wzór drivers/macintosh/rtc.c, będą mogli także, bez kłopotów, tego użyć.

właściwe wsparcie dla TLS w kompilatorach (oraz glibc/pthreads) jest rzeczą nieco problematyczną na platformie x86. Istnieje tutaj tylko 8 rejestrów ogólnego przeznaczenia, więc na architekturze x86 musimy używać segmentacji aby uzyskać dostęp do TLS. Glibc korzystały ze stworzenia wpisu, który definiował TLS dla każdego z wątków. Oprócz ogólnych niedoskonałości LDT, wprowadzało to także limit: maksymalna liczba wpisów (entries) w LDT to 8192, więc jest to także maksymalna liczba wątków przypadających na aplikację.

łatka wprowadza zupełnie inne podejście - jądro przechowuje specyficzny, osobny dla każdego wątku wpisu w GDT (GDT entry), który może być modyfikowany przez ten wątek:

asmlinkage int sys_set_thread_area(unsigned int base, unsigned int limit, unsigned int flags)

jądro, przed przełączaniem kontekstu, modyfikuje wpis GDT, aby był zgodny z ustawieniami TLS dla każdego wątku. W ten sposób, wątki w przestrzeni użytkownika mogą uzyskać dostęp do ich specyficznych danych za pomocą tego deskryptora - poprzez używanie tego samego, stałego przełącznika %gs (lub %gs). Liczba przestrzeni TLS jest nieograniczona i nie wymaga żadnych dodatkowych alokacji związanych z obsługą TLS.

Największym problemem, który nie pozwalał na wprowadzenie tej idei był Linuksowy, globalnie dzielony GDT na systemach SMP. Łatka radzi sobie z tym poprzez implementację GDT dla każdego procesora z osobna. To powoduje także szybsze przełączane kontekstów. 2-zadaniowe przełączanie kontekstów typu lat_ctx przyspieszyło o ok. 5% na mojej testowej maszynie z dwoma procesorami Celeron. [ Czy wynika to z faktu, iż współdzielonie GDT jest jest niezbyt optymalne na maszynach SMP? a może uaktualnianie bitu 'accessed' w deskryptorach DS/CS powoduje pewien rodzaj związanego z nakładem cyklu blokad pamięci? ]

opis GDT uprościł się:

* 0 - null
* 1 - segment Thread-Local Storage (TLS)
* 2 - segment kodu jądra
* 3 - segment danych jądra
* 4 - segment kodu użytkownika <==== nowa cacheline
* 5 - segment danych użytkownika
* 6 - TSS
* 7 - LDT
* 8 - obsługa APM BIOS <==== nowa cacheline
* 9 - obsługa APM BIOS
* 10 - obsługa APM BIOS
* 11 - obsługa APM BIOS
* 12 - obsługa PNPBIOS <==== nowa cacheline
* 13 - obsługa PNPBIOS
* 14 - obsługa PNPBIOS
* 15 - pbsługa PNPBIOS
* 16 - obsługa PNPBIOS <==== nowa cacheline
* 17 - nie używane
* 18 - nie używane
* 19 - nie używane

set_thread_area() obecnie rozpoznaje nastepujące flagi:

#define TLS_FLAG_LIMIT_IN_PAGES 0x00000001
#define TLS_FLAG_WRITABLE 0x00000002
#define TLS_FLAG_CLEAR 0x00000004

• w teorii moglibyśmy uniknąć bitu 'limit in pages', ale chciałem zachować elastyczność w tej kwestii aby, na przykład, potencjalnie uaktywnić podzielone na bajty segmenty stosu. Nielimitowana liczba segmentów (rozdrobnienie = strony, limit = 0xfffff) może przynieść pewne przyspieszenie na niektórych typach procesorów. Moglibyśmy także automatycznie znajdować najlepsze, możliwe ,,rozdrobnienie'' dla zadanego limitu - ale osobiście chciałem uniknąć tego typu ,,zgadywanek''. Niektóre procesory mogą mieć zalety w użyciu segmentów z limitami stron - kto wie.
• Flaga 'writeable' jest bezpośrednia i może być użyteczna w stosunku do niektórych aplikacji.
• Flaga 'clear' czyści TLS. [proszę pamiętać, iż limit zerowy o adresie 0 jest w gruncie rzeczy prawidłowy, jest to, po prostu, jednobajtowy segment o adresie 0.]

(to wywołanie systemowe nie udostępnia żadnych innych opcji segmentu przestrzeni użytkownika, jego stopień uprzywilejowania to 3, a segment jest 32-bitowy itp. - używane są bezpieczne i rozsądne wartości.)

INFROMACJA: interfejs ten celowo nie umożliwia zmiany TLS dla innego wątku - to by tylko niepotrzebnie skomplikowało interfejs (oraz implementację). Czy istnieje jakikolwiek dobry powód dla umożliwienia zmiany parametrów TLS innego wątku?

INFROMACJA2: nie używające wątków aplikacje mogą wywoływać set_thread_area() w celu ustanowienia wpisu GDT zaraz poniżej końca stosu. Możemy równie dobrze używać domyślnej przestrzeni TLS, lecz to usztywni segment.

poprawiłem także kilka rzeczy w obsłudze GDT/IDT:

• wskaźnik 'gdt' jest całkowicie niepotrzebny, wprowadza tylko dodatkowe przekierowania.
• to samo ze wskaźnikiem 'idt'.
• powoduje to także łatwiejsze tworzenie deskryptorów GDT/IDT.
• na systemach jednoprocesorowych GDT staje się mniejsze o kilka bajtów :-)
• zostało wyczyszczone ładowanie LDT: load_LDT_desc() teraz ładuje stały przełącznik LDT. Szkoda, że musimy to robić - ale jest to konieczne, by wyczyścić deskryptory zapasowe/cienie LDT.
• ścieżka przełączania kontekstu wątków zawiera wywołanie funkcji, która nie jest rozwijana w miejscu wywołania - set_ldt_desc() - ta funkcja jest teraz 'inline'.

łatka kompiluje się, ładuje oraz działa działa świetnie na jedno- i wieloprocesorowych architekturach x86. Komentarze i sugestie mile widziane,

UML został zaktualizowany do 2.5.28 i 2.4.18-44. Zmiany od 2.5.27 zawierają:

• Reorganizację konfiguracji i porządki w Makefile
• Procesy UML mogą byż zauważane przez mconsole przy użyciu /proc/mconsole
• SCSI teraz działa. Tylko niskopoziomowe sterowniki są na razie dostępne tj. sterownik scsi_debug w pamięci.
• Zestaw błędów w honeypot został naprawiony
• Usunąłem kilka problemów z hostfs, ale nadal nie działa.

Ponieważ UML nie trafił do 2.5.27, to będę wysyłał tę łatkę Linusowi.

Łata dostępna jest tutaj:
http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.28-1.bz2

Inne serwery lustrzane UML oraz innych możliwości pobrania są wymienione pod adresem:
http://user-mode-linux.sourceforge.net/dl-sf.html

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

Tu nie chodzi o serwer. Mam dla nich serwer. Sądzę, że wiele osób nie zdaje sobie sprawy z tego jak wiele czasu Jon i spółka spędzają nad przygotowywaniem LWN; chodzi dokładnie o ten *czas*, który uniemożliwia im robienie czegokolwiek innego.

Porównaj ich z poświęconym Linuksowi Theregister.co.uk - prawdziwe dziennikarstwo z analizami, które przewyższają te dostarczane przez CmdrTaco (choć te są chyba bardziej zabawne) i im podobne.

Żeby móc robić LWN, muszą znaleźć sposób na życie, który umożliwi im poświęcanie czasu na to. Nie mogą tego robić oprócz codziennej pracy.

Bez dwóch zdań. Nie możesz robić strony z nowościami, strony jakości LWN, przy pomocy 100 ochotników, z których każdy spędzi 2 godziny tygodniowo na zbieraniu informacji.

Zamiast tego potrzebujesz kilka naprawdę dobrze poinformowanych osób. To kosztuje pieniądze, bo ci ludzie nie będą mieli czasu na robienie innych rzeczy, za które zapłacą swoje rachunki.

Daję teraz jakieś pieniędze. Jeśli to nie oszczędzi ich na jeszcze trochę, to będę o nich myślał jako o opłacie za prenumeratę i podziękowaniu...

http://old.lwn.net/corp/donate/

Właściwie jedynym, interesującym aspektem toczącej się dyskusji EVMS vs. device-mapper, który został całkowicie pominięty, to fakt, iż EVMS potrafi zarządzać wszystkimi urządzeniami blokowymi.

Na początku ,,wchłaniane'' są wszystkie urządzenia blokowe w celu stworzenia różnych przypisań (LVM, RAID, itp.), a na końcu ,,wyrzuca'' je jako główne urządzenia EVMS. Zawierają się w tym urządzenia, które nie zostały zamapowane, takie jak: hdXY lub sdMN. EVMS posiada udogodnienia, które zapewniają, w razie potrzeby, powtarzalność numerów głównych i pobocznych, ale które są przydzielane tylko w przypadku realnej potrzeby.

Obecnie EVMS posiada tylko jeden numer typu głównego ale w moim rozumieniu to powinno móc przejąć wszystkie numery główne urządzeń SCSI oraz IDE. Nie będziemy musieli się już martwić o alokację numerów rzadko spotykanych urządzeń oraz będziemy mogli posiadać bez żadnych problemów, tysiące dysków/partycji.

Taka jest wola Linusa. Powtórzył to na Linux Summit. Ale, aby zrobić to porządnie (= czyli nie za pomocą EVMS) potrzebujemy do tego się przygotować. Al obecnie dużo pracuje nad uczynieniem urządzeń blokowych bardziej niezależnymi od ich numerów głównych. A kiedy to się stanie i sterowniki nie będą potrzebowały wewnętrznie głównych numerów urządzeń, pozostanie tylko zapewnienie wstecznej zgodności na poziomie programów użytkowych.

Jestem całkiem pewien, że przygotowania zakończą się już dla 2.6, ale nie mogę stwierdzić, czy unifikacja głównych numerów dysków zostanie skończona.

Wersja 215 mojej łatki devfs jest teraz dostępna na:

http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html

FAQ devfs jest także tutaj dostępne.

Łata do pobrania bezpośrednio z:

ftp://ftp.us.kernel.org/pub/linux/kernel/people/rgooch/v2.5/devfs-patch-current.gz

i:

ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.5/devfs-patch-current.gz

UWAGA: Jądra 2.5.1 i starsze wymagają devfsd-v1.3.19 lub starszego.

To jest dla 2.5.28. Ważniejsze rzeczy w tym wydaniu:

• Utworzenie <devfs_find_and_unregister>
• Przełączenie wielu funkcji z <devfs_find_handle> do <devfs_find_and_unregister>
• Przełączenie wielu funkcji z <devfs_find_handle> do <devfs_get_handle>

Ludziom, którzy wciąż nie mają karty dźwiękowej, chciałbym przedstawić sterownik pc-speakera. Gdzieś w sieci pałętają się inne takie sterowniki, ale z tego co wiem, żaden z nich nie jest naprawdę ukończony i używalny.

Mój sterownik jest oparty na sterowniku Michaela Becka i Davida Woodhousa, ale jest istotnie przerobiony i pretenduje do bycia w 100% zgodnym z OSS, produkując prawie najlepszy dźwięk jaki ktokolwiek kiedykolwiek może uzyskać z pc-speakera. Cóż, (obecnie) nie mam w zamiarze zgłaszać go do umieszczenia w głównym jądrze, więc nie traktujcie go zbyt serio. Komentarze i raporty o błędach będą jednak docenione.

Najnowsza łata na jądro 2.4.18 jest dostępna tu:

http://www.geocities.com/stssppnn/pcsp.html

Właśnie. Zaznaczyłem to jako zdezaktualizowane lata temu, a kiedy chciałem to wyciąć, to Linus powiedział, że lubi /proc/pci i musi ono zostać.

Wciąż myślę, że to ekstremalnie obrzydliwy interfejs, szczególnie dlatego, że wymaga, by jądro zawierało listę nazw producentów i urządzeń.

Sądzę, że powinieneś wyjaśnić to z Dave'em. Został zawalony robotą nad 2.4, ale nie sądzę, że kiedykolwiek planował porzucić opiekę nad projektem, tylko dlatego, że to 2.5.

Nikt nie zaprzecza, że Anton sporo pracuje nad tym, żeby ppc64 w 2.5 było aktualne, ale to nie oznacza automatycznej zmiany opiekuna.

Użyteczny jest BK - jazda próbna - http://www.bitkeeper.com/Test.html

Obejrzyj też slajdy itp. z wykładu Val Henson na OLS; są na jej stronie - http://www.nmt.edu/~val/

Wyciąg z listy zmian:

• Poprawna zmiana umiejscowienia ia64 SEGREL. Naprawiono niepoprawne dane dla modułów dla ia64.
• Usunięto ostrzeżenia dotyczące 64 bitowych procesorów.
• Nowe aliasy. Bill Nottingham.
• Dodano R_PARISC_PCREL22F. Richard Hirst.
• Usunięto ostrzeżenie flexa.

Użytkownikom IA64, którzy debugują moduły, mocno polecamy aktualizację do tej wersji.

Mam już dość odpowiadania ciągle na te same pytania, więc postawiłem, że wyślę to tutaj.

Najbardziej powszechne pytanie, które ostatnio jest mi zadawane, można przedstawić w formie ,,Dlaczego nie ma 2.5-dj od .27?'' (Tia, całe dwie wersje i ludzie już się pocą z przejęcia).

• Ze względu na wielkie błędy sterowników w .28/.29/.30którezarazbędzie; nie mówiąc o problemach z kompilacją, nie miałem zbyt wiele szczęścia przy uruchamianiu ostatnich kilku jąder na większości moich maszynek. Jeśli nie uda mi się uruchomić 2.5-dj na wszystkich moich testowych maszynach, nie będę go publikował.
• Brak czasu. Zajmuję się x86-64 i innymi projektami.
• Wakacje. W piątek biorę wolne i na tydzień znikam na prawdziwe wakacje, pierwszy raz od roku. To znaczy, że nie będzie mnie w sieci.

W ostatnim punkcie zaznaczyłem ważną zmianę w moim sposobie pracy. Spędziłem trochę czasu próbując zdecydować, jak się się udać na wakacje, żeby nie wrócić do nocnego koszmaru synchronizacji wszystkiego po przerwie. Puryści z FSF mnie znienawidzą, ale znowu zacząłem bawić się BitKeeperem i tym razem się udało. (Ciekawi mogą popatrzeć na http://linux-dj.bkbits.net)

W tym tygodniu odłożyłem podsyłanie kawałków Linusowi, żeby wyraźnie utrudnić sobie życie, gdybym musiał synchronizować się z jego ostatnim drzewem ręcznie, by zobaczyć, czy bk naprawdę sobie z tym radzi. Do tej pory, to co zwykle zabiera mi większą część godziny, może być teraz zrobione w ciągu 10 minut.

Zatem po moim powrocie, ponowna synchronizacja powinna być mniej bolesna niż kiedyś i zabiorę się za przesyłanie Linusowi niektórych rzeczy, które już na to od pewnego czasu czekają.

Ostatnia rzecz: Ze względu na to, że tydzień mnie nie będzie, niczego nowego nie włączę do mojego drzewa 8) Wysyłajcie jednak co macie, zajmę się tym po powrocie.

Można już ściągnąć SCTP dla jądra Linuksa w wersji lksctp-2_5_29-0_5_0.

Projekt lksctp został stworzony w celu implementacji protokołu transportowego SCTP dla jądra Linuksa.

Więcej informacji, kod źródłowy i łatki można znaleźć pod adresem:

http://www.sourceforge.net/projects/lksctp/

Łatka na wersję linux-2.5.29 może być bezpośrednio ściągnięta z:

http://prdownloads.sourceforge.net/lksctp/lksctp-2_5_29-0_5_0.patch?download