Kernel Traffic #191 For 2002/11/11

Uruchomiłem moje mikrotesty tafli dla 3 wersji:

• current
• generic_fls
• i386 asm zoptymalizowany fls

Test zgłasza najkrótszy czas dla 100 wołań kmalloc w pętli (Duron 700). Odjąłem narzut pętla/test.

32-bajtowe alloc:
current:         41 tyknięć
generic_fls:     56 tyknięć
bsrl:            54 tyknięcia

4096-bajtowe alloc: 84 tyknięcia
generic_fls:     53 tyknięcia
bsrl:            54 tyknięcia

Różnica 40 tyknięć dla -current pomiędzy 4096 a 32 bajtami - ~4 cykle dla każdej pętli. bit scan jest o 10 tyknięć wolniejszy dla alokacji 32 bajtów i o 30 tyknięć szybszy dla alokacji 4096 bajtów.

Nie ma różnicy pomiędy generic_fls a bsrl - łatwo można przewidzieć wszystkie rozgałęzienia w generic_fls dla stałych wołań kmalloc.

Zgadzam się, mam starą łatkę, która to robi.

http://www.colorfullife.com/~manfred/slab/patch-km_div

Zignorujcie proszę część dotyczącą stałego przecinka, bo nie jest potrzebna, instrukcje 'div' są teraz poza centrum zainteresowania.

Problem polega na tym, że drzewo -mm zawiera około 10 łatek dla tafli. Chcę je zobaczyć w drzewie Linusa, zanim dodam następne łatki.

Nie jestem pewien, czy ext2meta będzie wystarczające. To nie tylko kwestia modyfikacji metadanych na dysku, co będzie potrzebne dla defrag, ale będę również potrzebował modyfikować część wewnętrznych danych w strukturach danych systemu plików ext2/3. Na przykład, gdy zmieniasz rozmiar systemu, to musisz zwiększyć liczbę deskryptorów grup, co oznacza, że musisz wykonać kmalloc, skopiować, a potem zwolnić sbi->group_desc na zamontowanym systemie plików.

Nie mam wątpliwości, że ext2meta może być zmodyfikowane i może sięgać po wewnętrzne struktury danych systemu plików ext2/3. Ale związane z tym problemy z blokowaniem powodują bałagan.

Mój oryginalny plan zakładał zaadaptowanie łatki Andreasa Dilgera, która pozwalała zmieniać rozmiar, żeby użyć nowego układu grup bloków, co pozwoliłoby ominąć wymaganie położenia systemu plików i uruchomienia ext2prepare. Nie jestem przeciwny próbie zrobienia tego przy użyciu ext2meta, ale wydaje mi się, że to może się dość szybko skomplikować.

Pierwsza publikacja squashfs. Squashfs jest bardzo kompresowalnym systemem plików dla Linuksa tylko do odczytu (jądra 2.4.x). Używa kompresji zlib do pakowania zarówno plików, i-węzłów, jak i katalogów. I-węzły w systemie są bardzo małe i wszystkie bloki są tak pakowane, żeby zminimalizować narzut danych. Obsługiwane są bloki większe niż 4K, ale maksymalnie jest to 32K.

Squashfs jest przeznaczony do ogólnego użycia tylko do oczytu, do użycia jako archiwum i w systemach wbudowanych, gdzie wymagany jest niski narzut.

Squashfs jest dostępny pod adresem: http://squashfs.sourceforge.net.

Łatka nakłada się obecnie na 2.4.19. Więcej informacji na temat projektu systemu plików i o podobnych rzeczach w README.

Cramfs był inspiracją dla squashfs. Najogólniej, squashfs oferuje lepszą kompresję, obsługę większych plików i systemów plików i więcej informacji w i-węzłach.

1. Obsługiwane są bloki o rozmiarach do 32K - dane są kompresowane w 32K jednostkach, co pozwala osiągnąć lepszą kompresję niż udaje się to przy użyciu bloków 4K. W ogólnym przypadku, używanie bloków większych niż 4K nie jest dobrym pomysłem, bo VFS woła system plików w stronach 4K. Squashfs bezpośrednio umieszcza dodatkowe dane w cache stron.
2. Squashfs, oprócz danych z plików, kompresuje informację dotyczącą i-węzłów i katalogów. I-węzły/katalogi zwykle dają się skompresować w 50%, pojedyncze i-węzły mają średnio 8 bajtów lub mniej.
3. Wszystkie dane systemu plików są pakowane bajtami, oszczędzając parę bajtów na każdym i-węźle i katalogu.
4. Składowane są pełne 32-bitowe uidy i guidy (4 bity w i-węźle, używana jest tablica wyszukiwania, żeby dostać 48 uidów/16 gidów). Obsługiwane są pliki o wielkości do 2^32. Jest trzymany stempel czasowy. Cramfs obcinał uidy do 16 bitów, gidy do 8 bitów. Rozmiary plików w cramfs nie przekraczały 2^24. Nie było stempla czasowego. Squashfs korzysta z kompresji metadanych tak, żeby mieć więcej informacji przy mniejszym narzucie.
5. Zawartości dowiązań symbolicznych czy indeksów plików są przechowywane wewnątrz tablicy i-węzłów, co daje lepszą kompresję niż gdyby były kompresowane osobno albo w ogóle.
6. Program mksquashfs nie przechowuje/mmapuje systemu plików tak, jak został on zrobiony (wykonuje sprawdzenie duplikacji plików na częściowo zapisanym skompresowanym systemie plików), więc pozwala na tworzenie większych systemów plików.

Więcej informacji jest zawartych w README...

Skompresowany system plików z możliwością pisania być może będzie moim następnym projektem... Jak wspomniało parę osób, takie systemy są dostępne.

Jak wiecie, w projektowaniu systemów plików zawsze jest coś za coś; bardzo trudno jest uzyskać tak dobrą kompresję, gdy umożliwa się pisanie, jak tę, gdy system jest tylko do odczytu. Chciałem uzyskać maksymalną kompresję i całkiem wiele technik, których użyłem opiera się na tym, że system jest tylko do odczytu.

System, który pozwala jedynie dołączać, ale nie modyfikować pliki mógłby okazać się sensownym kompromisem. Przy skompresowanych metadanych, dowolna modyfikacja plików spodwoduje inne wyniki kompresji, więc modyfikacja metadanych/plików ,,w miejscu'' nie jest możliwa. Dołączanie zmodyfikowanych metadanych i danych powoduje, że musimy mieć system plików z księgowaniem, a wymaganie czyszczenia tego logu powoduje stratę kompresji.

Skompresowany system plików z dynamicznie aktualizowanymi plikami z dostępem bezpośrednim sam się szybko sfragmentuje (Włazisz gdzieś do środka pliku, zapisujesz blok, idziesz gdzieś indziej, zapisujesz inny blok, powtarzasz to 1000 razy... Trzeba pamiętać, że nowy skompresowany blok danych będzie prawie na pewno miał inny rozmiar niż ten stary... To bałagan.)

Moje potencjalne wykorzystanie jest następujące: mam małą dystrybucję linuksa, którą sam złożyłem i nazwałem ,,firmware linux''. Buduję ją ze źródeł i w wyniku mam obraz zisofs zamontowany po loopbacku jako główny system plików. (Wersję bardzo alfa można zassać z: http://216.143.22.141/firmware/fwl-0.8.tar, wyedytować 'build.sh' żeby określić katalog wyjściowy, a potem uruchomić. Wszystko polega na tym, że cały system operacyjny i wszystkie aplikacje mogą być uaktualniane przy pomocy jednego pliku. Nie ma żadnego zarządzania pakietami, mamy tylko jeden wielki obraz.)

Powodem, dla którego użyłem zisofs zamiast cramfes jest to, że cramfs ma DUŻO problemów z dużymi systemami plików. (Końcowa partycja root, z apache, sambą, ntopem, pythonem, rsyncem, openssh i wszystkim w ogóle, zajmuje obecnie około 100 mega. Jasne, jeśli będe miał czas, mogę to trochę zmniejszyć, ale teraz kompiluję i rozwijam to na samym sobie, więc mam tam gcc, cały zestaw podręczników systemowych i wszystko..)

Mkcramfs chyba się krztusi na czymś, co ma około 16 mega, co jest naprawdę ograniczające. Wydaje się TEŻ, że próbuje otworzyć równocześnie wszystkie pliki (wykrywanie twardych dowiązań?), więc zaczyna mu brakować uchwytów plików (Znowu, to można poprawić gdzieś w /proc, ale nie warto.)

Wydaje mi się zatem, że lepiej to testować na zisofs niż na cramfs. Patrzyłeś na to?

Spojrzę na to sam i dam Ci znać...

Podczas pisania squasfs oglądałem cramfs i ziosfs. Ziofs jest fajnym systemem plików, ale ma tendencję do większego narzutu spodowodwanego systemem plików isofs. W trakcie testów stwierdziłem, że obrazy zisofs są większe od systemu plików squashfs o od 5% (pojedynczy katalog z wieloma małymi binarkami) do 61% (dużo zagnieżdżonych katalogów).

Wierzę, że squashfs jest użyteczny dla Twoich zastosowań. Troszkę się waham, mówiąc to, bo wolałbym żeby ludzie sami sobie go ściągneli i sami wyrobili sobie pogląd na tę sprawę :-)

Dziękuję za wypróbowanie tego, mam nadzieję, że się spodobało. Oczywiście jestem zainteresowany Twoimi przemyśleniami na ten temat.

Duże zmiany, mnóstwo włączeń. Część z nich naprawdę istotna.

Device mapper (LVM2), rzeczy sieciowe typu crypto/ipsec, epoll i szansa dla nowego konfiguratora jądra. Duże rzeczy.

I _dużo_ doraźnych modyfikacji, od różnych uaktualnień architektur po USB, ISDN i ALSA. Łączenie z Andrew & Alanem i innymi. Bierzcie i testujcie.

Poniżej załączam pierwszą z kilku zmian dla initramfs / wczesnego uruchamiania w przestrzeni użytkownika.

Ta zmiana jest celowo bardzo prosta i nie da wyobrażenia swojej wartości aż do następnego tygodnia, kiedy to łatki numer 2 i 3 przybędą do Waszych skrzynek. Opis ,,przyszłości'' umieściłem po opisie tego szczególnego zbioru zmian.

1. Wprowadzone zostało samo init/initramfs.c, które jest modułem, który dekompresuje archiwum .cpio.gz i używa go do zasilenia rootfs plikami, bardzo wcześnie w procesie startowania systemu (między signals_init i proc_root_init w init/main.c). Zobaczycie krótką listę rozpakowanych plików w dmesg. Musimy to na razie zostawić (na razie jest to też małe), ale być może usuniemy te napisy na ekranie/w logu, albo wrzucimy do KERN_DEBUG jeszcze przed wypuszczeniem 2.6.x:

      -> plik1
      -> plik2
      -> itp...

   (uwaga opiekunowie architektur!)

2. Wprowadzono ARCHBLOBLFLAGS do arch/$arch/Makefile, żeby móc zamienić dowolny binarny obiekt w plik .o używając objcopy.
3. Włączono archiwum initramfs cpio do obrazu vmlinux przez arch/$arch/vmlinux.lds.S w sekcji init.
4. Wprowadzono nowy katalog linux/usr. Aktualnie nie jest zbyt interesujący, zawiera tylko mały programik, który generuje początkowe archiwum cpio, gen_init_cpio. Program zniknie, gdy wczesne wejście w przestrzeń użytkownika będzie się rozwijało. Obecnie istnieje, aby pokazać, że initramfs działa, umożliwiając nam usunięcie trzech linijek z init/do_mounts.c.

Wczesne wchodzenie do trybu użytkownika zostanie włączone w formie serii ewolucyjnych zmian, zgodnie z tym co nazywam ,,modelem Ala Viro''. ZACHOWANIE JĄDRA NIE POWINNO SIĘ ZMIENIĆ. [to dla słuchaczy lkm, nie dla Ciebie <g>] 'make' wciąż będzie Działało Właściwie (tm) na wszystkich platformach, podzczas, gdy obraz jądra będzie się ciągle zmniejszał. Oto początkowy plan ,,wczesnego trybu użytkownika'', to znaczy opis łatek, które zobaczycie w przyszłym tygodniu:

#2 - włączenie klibc.

Jak już wcześniej powiedziałem, nie jestem pewien, czy uda się usunąć klibc przed wypuszczeniem 2.6.x, czy nie. Komentarze mile widziane. Na razie klibc będzie włączona do paczki z jądrem, bo w przeciwnym wypadku zmiana wersji w trakcie ewolucji wczesnego trybu użytkownika byłaby prawdziwym wrzodem na dupie i spowolniłaby go. klibc to malutka libc napisana specjalnie dla jądra.

Ta łatka doda klibc do systemu budowania jądra i stworzy maleńki, statycznie dołączany binarny plik ,,kinit''. kinit to początki wczesnego trybu użytkownika. Odrobina kodu z do_mounts.c przejdzie do kinit w łatce #2, tylko tyle, żeby udowodnić, że system działa.

#3 - przeniesienie initrd do trybu użytkownika

Niestety, aż do tej łatki nie zobaczymy pożytków płynących z wczesnego trybu użytkownika, ale tak działa ewolucja :) Tutaj kod odpakowujący initrd jest przenoszony do trybu użytkownika, przenoszone jest wszystko, co jest możliwe do przeniesienia. Część kodu initrd musi zostać w jądrze, bo to, jak uzyskać obraz initrd z bootmem [albo skądkolwiek] zależy od architektury, ale istotna większość kodu initrd przeszła test (oja!). Zachowanie initrd nie zmieni się zupełnie. Zostanie tylko po prostu przesunięte do wczesnego trybu użytkownika. Użytkownicy nie będą musieli sami nic robić, żeby upewnić się, że ich istniejące konfiguracje działają -- wymaganie takiego działania jest moim błędem.

Ta łatka zamieni także 'kinit' na współdzielone binarium i wprowadzi binarkę gzip do wczesnego trybu użytkownika. [odnośnie tego patrz też na ,,pozycje do dyskusji'' poniżej]

#4 - przesunięcie montowania roota do trybu użytkownika

Ludzie już prawdopodobnie odetchnęli z ulgą przy łatce #3, jeszcze głębiej odetchną przy tej łatce :) Przesuwa ona montowanie systemu plików root do wczesnej przestrzeni użytkownika, włączając w to pozbycie się kodu NFSroot/bootp/dhcp z jądra.

#N - do nieskończoności ... i jeszcze dalej!

Będę, i mam nadzieję, że inni też, kontynuował serię łatek ewolucyjnych i będę przesuwał coraz więcej rzeczy do wczesnego trybu użytkownika. Możliwości jest wiele, czekam na doniesienia innych na temat użytecznych rzeczy do przesunięcia, sam też będę pracował nad znalezieniem takich rzeczy.

Pozycje do dyskusji:

#1 - współdzielone kinit

'kinit' jest binarką wczesnego trybu użytkownika, ale niekoniecznie jedyną taką. Peter Anvin i Russell King mają trochę binariów w paczce klibcowej: gzip, ash i kilka mniejszych narzędzi. Peter włożył także trochę pracy w to, żeby klibc był obiektem współdzielonym, który nie potrzebuje shlib. Moim zdaniem zrobił to pierwszorzędnie: binaria skonsolidowane z klibc są dla systemu ELF binariami statycznymi, ale dzięki pewnemu trikowi współdzielą klibc.so.

W każdym razie, jest pewna elegancja w dodaniu kodu do kinit zamiast eksplozji binarek i skryptów powłoki. Jest jednak druga strona medalu - dla elegancji poświęca się łatwość dokonywania zmian. Jestem w 60% pewien, że chcemy współdzielonego klibc i wielu binariów, ale jestem też skłonny zgodzić się z przeciwnym zdaniem. Po przemyśleniu, wydaje się, że _jest_ trochę korzyści z zostawienia kinit w formie pojedynczego pliku binarnego w jądrze z wczesnym trybem użytkownika. Decyzja nie była zatem taka prosta, jak to może się od razu wydawać.

#2 - klibc w paczce jądra

Wchodzi, narazie. To nie podlega dyskusji. Jednakże w przyszłości... Znam starą maksymę głoszącą, że ,,jak raz weszło, to już nigdy nie wyjdzie''. Być może to jest właśnie ten przypadek, ale jeśli nawet, to co z tego. Znam conajmniej kilka osób, które chciałyby, żeby klibc opuścił źródła jądra przed wydaniem 2.6.0. Oczekuję komentarzy na ten temat, choć myślę, że nie będziemy w stanie odpowiedzieć na to pytanie zanim termin wydania 2.6.0 nie stanie się naprawdę bliski.

I to by było na tyle. Pytania, komentarze i oburzenie mile widziane. Jeśli opuściłem jakieś korzyści z wczesnego wejścia w przestrzeń użytkownika, to dajcie mi znać. Jeśli wiecie o jakichś dobrodziejstwach wynikających z przejścia do wczesnego trybu użytkownika, to dajcie mi znać. Jeśli na mojej drodze są jakieś przeszkody, o których nie wspomniałem, to dajcie mi znać.

Podziękowania: Al Viro za pracę nad initramfs. hpa, rmk, Greg KH, Alan i niezliczona liczba innych osób, które poddały pomysły, jeśli nie sam kod, przybliżające uzyskany wynik. I dziękuję naszemu Pingwinowi Imperatorowi za to, że dał mi spokój, gdy przegapiłem Halloween, bo spędziłem 24 godziny na szukaniu mojego _niewiarygonie_ głupiego błędu. Zasłużyłem nie na jedną, ale na dwie torby z szarego papieru.

Zauważcie, że powodem, dla którego osobiście chciałem mieć initramfs nie było zmniejszenie obrazu jądra, ani zmniejszenie jego źródeł. To nie zdarzy się jeszcze długo, jako że podejrzewam, iż będziemy jeszcze trochę wozić ze sobą initramfs w przestrzeni użytkownika (w końcu pewnie się odłączy jako osobny projekt, ale oczywiście w przewidywalnej przyszłości będzie blisko związany z jądrem).

Prawdziwy zysk jest według mnie dwojaki:

• ułatwienie ludziom dopasowywania startu ich systemów bez potrzeby grzebania w kodzie jądra albo nawet używania innej sekwencji bootującej. Jednym z przykładów jest różnica między instalacyjnymi jądrami producenta (używającymi initrd) i normalnym jądrem instalacyjnym (które tego nie używa).

  Wolałbym, żebyśmy _zawsze_ używali initrd, a różnica między jądrem instalacyjnym a normalnym to po prostu rozmiar initrd.

• Wiele rzeczy łatwiej zrobić w przestrzeni użytkownika, bo jest ona chroniona, ma ,,nieskończony stos'' i ogólnie dużo lepszą infrastukturę (łatwiej w niej szukać błędów itp). Jednakże wiele rzeczy musi być zrobionych _zanim_ jądro jest w pełni gotowe na przejęcie kontroli nad zwykłą przestrzenią użytkownika; zrobić parsowanie ACPI tak, żeby móc zainicjalizować urządzenia, dzięki którym możemy użyć ,,prawdziwej'' przestrzeni użytkownika, która jest zainstalowana na dysku itp.

  Czasem te dwie rzeczy nachodzą na siebie (to znaczy występuje sytuacja ,,łatwiej zrobić w trybie użytkownika'' i ,,musi być wykonane zanim można załadować normalny tryb użytkownika''). ACPI jest potencjalnym przykładem. Montowanie systemu plików root po NFS-ie po DHCP albo innym autowykrywaczu to inny przykład.

Na mojej liście nie ma ,,skurczenia jądra''. To raczej kwestia tego, że ,,część incjalizacji lepiej zrobić w trybie użytkownika'', a nie głównie tego, że ,,chcemy mieć mniejsze jądro''. Nie wierzę zbytnio w mikrojądra i próby wydostania wszystkiego z jądra, ale _wierzę_, że czasem łatwiej jest pozwolić użytkownikowi na działanie zgodne z jego wyborem (dając mu jednak ochronę taką, jaką daje tryb użytkownika).

przestrzeń użytkownika jest bardziej ograniczona. I to nie jest czeski błąd - to dobra rzecz. Przestrzeń użytkownika musi używać normalnych wołań systemowych, nie wkłada swoich paluchów w cholera wie jakie struktury danych jądra.

To oznacza, że jest to bardziej pewne i nie staje na drodze pracy jądra. 90% bólu z super.c było tego typu - montowanie systemu plików root było robione przy pomocy ohydnych sztuczek i, co więcej, te paskudztwa były filtrowane w normalnej ścieżce wykonywania. Pozbycie się tego zabrało _dużo_ uważnych manipulacji w całości. I zgadnijcie co? Nie ma powodu, dla którego ta czarna magia byłaby niezbędna - obecny kod używa normalnych, dostępnych dla wszystkich, wołań systemowych.

W wyniku tego mieliśmy specjalne przypadki mount(2) itd, z bardzo nieporządną semantyką. Nie były one pokazywane przestrzeni użytkownika, bo to nie sprawiło, że były mniej paskudne, albo że łatwiej było z nimi pracować. One ciągle zaśmiecają kod, ciągle przeszkadzają w pracy nad tym i ciągle są paskudne.

I temu zapobieże przesunięcie kodu do przestrzeni użytkownika - dużo łatwiej złapać kogoś, kto daje łatkę z magicznym rozszerzeniem wołania systemowego, niż złapać próbę wciśnięcia kodu dotyczącego przypadku specjalnego, który jest używany tylko przez jądro.

W każdym razie, to jest rzecz, na którą musimy uważać - oczywiście będzie wiele łatek przenoszących coś do przestrzeni użytkownika i pojawi się silna pokusa dodawania magicznych interfejsów jedynie w tym celu. _Temu_ powinniśmy zapobiec - lepiej zostawić paskudne śmieci tak jak są, niż przenosić je do przestrzeni użytkownika. Wszystko polega na tym, żeby mieć wyczyszczony kod i upewnić się, że może zostać czysty, a nie poprawiać go dodając magiczne ioctl/syscalle/flagi/conieco. Możemy równie dobrze dodać coś do istniejących interfejsów, ale do cholery, lepiej upewniajmy się, że takie dodatki są sensowne w ogólnych przypadkach.

Mamy sporo paskudztwa, które nie byłoby potrzebne, gdybyśmy mieli wczesny dostęp do zapisywalnych systemów plików. Mamy magiczne metody, magiczne ścieżki wykonywania kodu itp, głównie dlatego, że normalny dostęp do żądanej funkcjonalności wymagał otwierania deskryptorów plików. Teraz _mamy_ zapisywalny system plików bardzo wcześnie montowany, zatem ten syf można wyrzucić. Przesunięcie kodu do przestrzeni użytkownika działa jak filtr - tam nie mamy dostępu do magii, więc cała ta magia nagle się pokazuje. To może być zrobione w jądrze (i całkiem wiele rzeczy zostało juz tam zrobionych), ale przejście do trybu użytkownika zrobi za strażnika niepozwalającego na ponowne wprowadzenie magicznego śmiecia.

Chciałbym ogłosić nowy projekt, którego celem jest stworzenie lub/i zebranie zestawu testów POSIX-owych API. Testy skupią się na zgodności z IEEE Std 1003.1-2001, ale będą także zawierały oddzielne testy funkcjonalności i zachowania przy dużym obciążeniu.

Obecne podejście projektu do testowania zgodności polega na zapisie twierdzeń wynikających z wnikliwego czytania specyfikacji POSIX i zapisaniu minimalnych przypadków testowych, które potwierdzą lub odrzucą te twierdzenia. Zestaw testów będzie niezależny od szczegółowych implementacji API, a na koniec będzie łatwo konfigurowalny w celu użycia go przy różnych implementacjach. Projekt zakłada niezależność od systemu operacyjnego, używa tylko API POSIX-owych, autoconfa i prostej obsługi w języku powłoki. Jest jednak obecnie testowany na Linuksie.

Docelowo, plan przewiduje użycie zestawu testów do oceny obecnego wsparcia POSIX w Linuksie oraz rozważenia nowych implementacji przez społeczność open source i przesyłania łat albo przynajmniej raportów o błędach (w minimalnych przypadkach testowych) we właściwe miejsca, takie jak LKML.

Przypadki testowe, przeglądy mojej pracy, dyskusje podejścia do sprawy itp. są mile widziane. Zapiszcie się na listę dyskusyjną, posixtest-discuss. Na początku skupiamy się na sygnałach, kolejkach komunikatów, wątkach, semaforach, zegarach i licznikach czasu. Wybór ten wynika z aktualnych zainteresowań i zasobów. Możecie pomóc w tym obszarze, albo zacząć pracować nad innym kawałkiem specyfikacji. W całym zestawie potrzebne będzie pewne ujednolicenie, ale wiele szczegółów musi być jeszcze dopracowanych, zatem Wasze zaangażowanie w podjęcie tych decyzji będzie bardzo pomocne.

Więcej informacji o projekcie znajduje się pod adresem: http://posixtest.sourceforge.net

Świetny pomysł. Możemy pomóc Ci w następujący sposób: BitKeeper ma wyjątkowo proste oprzyrządowanie do testowania, używane do regresji. Wiadomo dobrze, że bardzo łatwe jest pisanie prostych testów i uruchamianie ich osobno lub w zestawie. Jeśli chcesz to oprzyrządowanie, to damy Ci je na takiej licencji, na jakiej chcesz, zakładam, że będzie to GPL, ale zbytnio nam na tym nie zależy.

Możesz zobaczyć jak wyglądają testy w BK, jeśli masz go zainstalowanego, dostarczamy wszystkie testy, są umieszczone w `bk bin`/t

Prosty test mógłby wyglądać następująco:

        #!/bin/sh

        # sprawdzenie, czy touch tworzy plik
        touch foo
        test -f foo || {
                echo nieudane stworzenie foo
                exit 1
        }

Nasze oprzyrządowanie dba, żeby odbyło się to w czystym, wyizolowanym środowisku.

Ciekawi mnie, czy jacyś producenci albo niezależne grupy byliby zainteresowani w utrzymywaniu zestawu łatek na jądro, dającego zgodność jądra Linuksa z POSIX?

Moim zdaniem projekt ,,POSIX Linux'' byłyby użyteczny z kilku powodów. Najogólniej, wydaje mi się, że z paru stron istnieje pewna presja na to, żeby w jądrze znalazły się wszystkie rodzaje API z POSIX. Czasami hakerzy jądra stają w sytuacji, w której zupełna zgodność z POSIX może oznaczać kompromis w jakimś obrzarze, to może być wydajność, bezpieczeństwo, kwestie API, problemy z czyszczeniem kodu, itp. Albo po prostu kod POSIX-owy nie jest po prostu jeszcze gotowy do włączenia do głównego jądra.

Producenci także mieliby z tego zysk, bo zmniejszyłaby się bariera wejścia w przypadki związane z POSIX, co potem zamieniłoby się w spełnienie oczekiwań klientów. Co z kolei dałoby głównemu drzewu jądra wszystkie korzyści wynikające z bardziej sensownego przeglądania i włączania nowych cech.

Czy coś takiego już istnieje? To musiałby być projekt otwarty, niezależny od producenta...

Pojawia się coraz więcej ludzi, którzy chcą się ode mnie dowiedzieć, komu mogą zapłacić za naprawienie drobnych błędów w Linuksie i mają problem w znalezieniu mniejszych firm. Oczywiście, jeśli chce się wysłać 1000$ za naprawianie sterownika, to nie działa to w przypadku, gdy mamy do czynienia z dużymi firmami.

Jedną z rzeczy, które robi FSF i która ma sens, jest trzymanie w pakietach listy ludzi, którym można zapłacić, żeby coś w tych pakietach poprawili. Zadałem pytanie na Linux-kernel i dostałem mały, początkowy zbiór odpowiedzi z firm. Mam nadzieję, że będzie ich więcej po włączeniu tej łatki.

Lista jest alfabetyczna w wystarczająco logiczny sposób

[Marcelo, to się nakłada ładnie także na 2.4 ]

Naprawdę wolałbym gdyby były jakieś wyraźne wytyczne co do tego. Jeśli nawet nie popieram tego, nie chciałbym, żeby podrzucono nam tam nieświeże jajeczko (zakładając, że lista bardzo się rozszerzy, co myślę, że może się stać) i powstały z tego powodu problemy.

Wolałbym także, żeby było to wyraźnie przeznaczone tylko dla pojedynczych osób i małych firm (,,mniej niż x ludzi''), albo żeby w jakiś inny sposób zapewnić, że jest to zrównoważone i że odpowiada oczekiwaniom ludzi (zarówno użytkowników listy jak i ludziom, którzy się na niej znajdą).

I czy źródła jądra są naprawdę właściwym miejscem ku temu, mając na uwadze fakt, że wiele osób będzie miało źródła sprzed kilku lat i nie będzie żadnego sposobu, by usunąć potencjalne problematyczne wpisy z już opublikowanych jąder? Innymi słowy, czy nie byłoby lepiej mieć jakieś miłe miejsce w sieci i odwołanie do tego miejsca w źródłach jądra?

Słuszna uwaga. Z przyjemnością umieszczę to na stronie i dam odnośnik. Czy są jakieś preferencje co do miejsca, czy to ma być kernel.org, czy po prostu 'gdziekolwiek'?

Podzielenie tego na firmy jest dość łatwe do zrobienia, podzieli się stronę na sekcje: ,,Zainteresowani kontraktami poniżej 1000$, 10000$, 100000$, 1M$, ...''

Sądzę, że możnaby skonstruować niezaprzeczalny schemat ocen. To zależy, czy to się opłaca.

,,Ludzie, którzy zapłacili za poprawki w sterowniku 3c501 podpisali także kontrakt na wsparcie MacIIfx...''

Pod poniższym adresem umieściłem wykresy pokazujące ewolucję cech jądra 2.5:

http://kernelnewbies.org/status/Linux_Kernel_2_5_Progress.png
http://kernelnewbies.org/status/Linux_Kernel_2_5_Compounded_Progress.png

Ponieważ większość rzeczy ewoluuje w czasie, a nie jest sprawą jednorazową, to wykresy te nie udają w pełni dokładnych, ale dają dobre wyobrażenie na temat cyklu rozwoju.

Zabawne, jak bardzo wzrosło tempo włączeń tuż przed zamrożeniem funkcjonalności :-)