Kernel Traffic #131 For 3 Sep 2001

Ukoñczyłem prace nad wersją 0.4 bootloadera Gujin dystrybuowanego na zasadach GPL.

Strona domowa projektu (ze zrzutami ekranów) jest tu:
http://gujin.sourceforge.net/
Dokumentacja (FAQ, HowTo) jest tu:
http://sourceforge.net/docman/display_doc.php?docid=1989&group_id=15465
Pozostałe informacje oraz źródła i prekompilowane pakiety są tu
http://sourceforge.net/projects/gujin/

Bootloader, w skrócie, umożliwia:

1. Pracę z PC-tami mającymi przynajmniej procesor 80386 oraz kartę graficzną VGA, VESA1 lub VESA2+.
2. Ładowanie obrazów jądra Linuksa (zImage i bzImage) bez pomocy LILO oraz przełączanie jądra z trybu rzeczywistego przy pierwszej instrukcji jądra wykonywanej w trybie chronionym. Możesz go użyć do ładowania dowolnego rozmiaru jądra i initrd, oraz z łatwością wybierać tekstowy lub graficzny tryb uruchamiania systemu.
3. jest prawie całkowićie napisany w C przy użyciu GCC, więc łatwo go modyfikować/poprawiać. Wykorzystuje e2fsprogs-1.22 do obsługi systemu plików E2FS oraz całkowicie przepisanej biblioteki zlib do rozkompresowania jądra. Działa również obsługa FAT12/FAT16.
4. pozostaje w trybie rzeczywistym przez cały proces butowania, więc powinien być zgodny ze wszystkimi PC-tami.
5. Może zostać zainstalowany jako bootloader (na razie jedynie na dyskietce) lub jako DOS-owy/Windowsowy boot.exe
6. 80% kodu jest już napisane, więc pozostaje napisanie ostatnich 80%, aby dojść do wersji 1.0 -:). IMHO jest to już dobry pomysł na dyskietkę awaryjną lub na porządny system ładujący z dyskietki (minimalna konfiguracja to ok. 20 Kb).

W chwili obecnej jest to możliwe jedynie przy instalacji Gujina na dyskietce lub przy generacji boot.exe. Wykonuje się to przy użyciu opcji "--cmdline=" programu "./instboot" - ta operacja dodaje parametry do każdego jądra, które będzie uruchamiane. Będziesz zatem musiał przekompilować ze źródeł.

Na razie nie ma możliwości podawania różnych opcji dla różnych jąder.

Popatrz także na "./instboot --help". Maksymalny rozmiar napisu to 64 bajty (można to zmienić przy kompilacji, popatrz do pliku boot.h, struct gujin_param_str->extra_cmdline).

Docelowo będzie konfiguracja, gdzie będzie można to pole zmieniać, ale najpierw potrzebny jest bardziej ogólne menu systemowe, a także sposób na wybór układu klawiatury.

Najwyższa pora wytłumaczyć, czemu tak zrobiłem - to rozwiązanie zdecydowanie nie jest najprostsze.

Po pierwsze, chciałem powiedzieć, że obecny interfejs Linuksa jest naprawdę stabilny: jeśli zdefiniujesz "BOOT_KERNEL_BEFORE_2_0" w vmlinuz.[c|h], Gujin będzie w stanie uruchomić wcześniejsze niż 1.0 wersje Linuksa. W ten właśnie sposób Gujin uruchamiał jądra do tej pory.

Rozgryzając interfejs jądra dla bootloadera, uznałem, że jest on ciut skompilowany: musisz nie tylko przekazać parametry w pamięci (pod adresem 0x9000:0000 lub w rejestrze %esi w 2.4.1+), ale także udostępnić odwołania (ang callback) (wywołania BIOS-u) dla wielu rzeczy.

Alan Cox opisał to (nie do koñca) w swojej wiadomości z czerwca, o tytule "Szkic dokumentu na temat wykorzystania BIOS-u przez jądro", dostępnej tu: http://marc.theaimsgroup.com/?l=linux-kernel&m=99322719013363&w=2

Musisz także umieścić w pamięci jeden lub skompresowane pliki (jądro i initrd) bez sposobności sprawdzenia, czy te setki kilobajtów zostały poprawnie odczytane i czy nie są uszkodzone. Nie ma możliwości - jeśli został wykryty błąd przez legacy loader w etapie dekompresji - powrotu do bootloadera mówiąc: Bład krytyczny, wybierz inne jądro.

Te dwa pliki w pamięci muszą być pod stałym adresem liniowym w trybie rzeczywistym - i jeśli masz menedżer pamięci (himem.sys) załadowany, te adresy mogą być zajęte. Zwykle, na dnie pamięci można znaleźć dane smartdrv. W takim przypadku niemożliwością jest załadowanie pliku pod losowy adres i pozostanie w trybie rzeczywistym, aby wykonywać dalsze przetwarzanie. Gujin natomiast mallocuje pamięć (wykorzystując himem.sys), ładuje i dekompresuje ten plik (sprawdzając jego CRC32), wyłącza przerwania, przełącza się do trybu chronionego, kopiuje ten plik oraz jego adres liniowy i wreszcie skacze do kodu jądra.

Później, wykorzystując "starą" metodę ładowania jądra, masz menu z wyborem trybu graficznego. Cóż, jest to dość skomplikowana rzecz do zaimplementowania w bootloaderze, a interfejs do niej jest naprawdę złożony (nie mówiąc o interfejsie użytkownika), zakładając, że już zapisałeś gdzieś w pamięci, nie wiedząc czy (na przykład) sterownik graficzny został załadowany. IMO, cały śmietnik z wyborem trybu graficznego musi być obsłużony przed wyborem jądra do załadowania.

Przypuszczalnie mógłbym znaleźć i inne problemy, ale nie chcę uprawiać destruktywnej krytyki.

Co proponuję? Zróbmy to prościej:

• Plik jądra to zwykły obraz binarny to załadowania pod adres 0x100000, więc uzyskujesz to z pliku typu linux ELF robiąc:
  objcopy -O binary -R .note -R .comment -S /usr/src/linux/vmlinux kernel
  gzip -9 kernel
  Nie ma żadnego limitu na jego rozmiar.
• initrd (o ile jest) jest zgzipowanym obrazem systemu plików.
• Wszystkie informacje, których potrzebuje jądro są umieszczone w pamięci. Są one w czytelny sposób opisane przez strukturę w C (vmlinuz.h::struct linux_param). Ta struktura zawiera także (dla porówania) stare pola, które nie są już używane i pola, które były używane jedynie przez poprzedni bootloader. _NIE_ ma odwołañ o BIOS-u.
• Sprzęt jest skonfigurowany poprawnie, na przykład, dla bieżącego trybu graficznego - jeśli jesteś w trybie 8bpp - ustawiona jest paleta 256 kolorów z sensownymi wartościami niezależnymi od karty graficznej. Mówiąc prościej, sprzęt może od razu być wykorzystany przez jądro.

• Istnieje tryb zgodności do załadowania vmlinuz/zImage/bzImage.

  Zauważ, że to wszystko jest już zakodowane i działa (taką mam nadzieję). Wiem, że przy tym rozwiązaniu, bootloader i jądro są mocniej ze sobą związane, ale wiem także, że bootloader musi być znacznie bardziej inteligenty (biorąc pod uwagę liczbę związanych z tym tematem wiadomości pojawiających się na Linuksowych listach). Nie powinien próbować ładować jądra skompilowanego dla Pentium na 486. Powinien konfigurować kartę graficzną (więc bądź gotów na otrzymanie "wyjątku nieprawidłowej instrukcji" przy wykonywaniu odwołañ do BIOS-u). Nie powinien ładować uszkodzonego jądra. Nie powinien się wywalać, jeśli plik z jądrem/initrd zmienił położenie, albo twarde dyski zamieniły się miejscami. Powinien wyświetlać jasne informacje na temat co złego się stało.

  Powinno zależeć od bootloadera czy się wykopyrtnąć, gdy odwołanie do BIOS-u spowoduje zmianę w rejestrze, który jest udokumentowany jako stały (jeśli się o to nie zatroszczył)

• w trybie DEBUG powinien wysłać jakieś informacje do portu szeregowego i równoległego. Gdy okaże się że BIOS ma błedy, to bootloader powinien się tym martwić, a nie jądro Linuksa.

W skrócie, to jest prawdziwe i pełne oprogramowanie, które obsługuje wszystkie/większość (błędnych) BIOS-ów w ich naturalnym środowisku: trybie rzeczywistym i386. Jeśli dojdą nowe pola do "struct linux_param" (co do tej chwili rzadko sie zdarzało), wówczas trzeba będzie zaktualizować Gujin. W każdym razie jest na GPL - i napisany w C, co umożliwi wielu ludziom modyfikacje w kodzie, co było trudne w przypadku kodu w assemblerze.

W rzeczywistości, z powodu odwowałañ konfiguracyjnych BIOS-u do APM / ACPI / PCI, nie jest to takie proste, jak opisałem; ale to się nie zmieniło przy bootloaderze Gujin. Zwróć także uwagę, że tablice SMP są przekazywane w pamięci.

Ostatnią rzeczą, którą chciałem dodać (dla ludzi, którzy doczytali do tego miejsca), to to, że po usunięciu "nagłówka" z pliku vmlinuz, brakuje mi jedynego istotnego parametru z tego nagłówka: urządzenia root (polecenie rdev). Teraz, zgaduję je w wielu konfiguracjach, ale to nie jest idealne rozwiązanie. Myślę, że jednym z prostszych rozwiązañ jest dodanie napisu "root=/dev/hd**" w polu komentarza w nagłówku GZIP; ale to nie jest jeszcze zaimplementowane.

Jeszcze z tej samej działki: nie ma sposobu, aby się dowiedzieć, czy jądro będzie w stanie się ładować w trybie graficznym (czy jest dostępny framebuffer VESA, i które tryby BPP są dostępne). Jeśli vesafb nie jest wkompilowane i wystartujesz jądro w trybie graficznym, to jądro się załaduje, ale na ekranie będzie śmietnik. Teraz używam do tego bitu zapisywalności pliku vmlinuz. Rozwiązanie ohydne i wkrótce powinno się zmienić.

Nie istnieje dobry powód na używanie 32bitowego punktu startu jądra. W szczególności dość powszechnie używam linuksa na systemach z dokładnie 10 16bitowymi instrukcjami. Na jednym z nich, nie mam nawet normalnej pamięci pomiędzy 640KB a 1MB. Tak naprawdę, jedynym parametrem, które jądro potrzebuje z BIOS-u to rozmiar pamięci, i mógłbym prawdopodobnie wziąć kod z memtest86, więc i tego bym nawet nie potrzebował.

Jednakże rozumiem problemy i braki w obecnym 32bitowym punkcie startu, oraz dlaczego używanie standardowego 16bitowego punktu wejścia jest dobrą rzeczą. Dlatego w 2.5 (o ile ta seria się kiedykolwiek zacznie) chcę włożyć trochę pracy w to, abyśmy mieli standardowy, międzyplatformowy natywny tryb dla punktu wejściowego dla jądra.

Aby zachować przenośność Linuksa nie powinniśmy zakładać istnienia na danej platformie określonego rodzaju BIOS-u. Przynajmniej Alpha-linux jest paskudny z tego powodu. Linux na x86 jest przyjemny, ponieważ, wszystko co potrzebujesz na platformach, które nie obsługują klasycznego interfejsu BIOS-u, to przerzucić się na 16bitowy nagłówek. To zdecydowanie jest struktura, którą warto zachować.

W tej chwili mam stabilną, łatwą do użycia strukturę, która nawet nie jest specyficzna dla linuksa i zawiera parę szczegółów więcej na temat, jak zakodować parametry, aby zadziałały. Struktura jest w formacie ELF dla statycznych plików wykonywalnych ze specyficzną implementacją, w jaki sposób parametry będą przekazywane do niego z bootloadera zanim bootloader zniknie. W szczególności - jak określić rzeczy takie jak urządzenia ISA na płycie, więc w przypadku urządzeñ, które nie obsługują próbkowania i nie ma interfejsu firmware do ich znalezienia, nie musimy nawet zakładać co jest, a co nie jest na płycie głównej. Ciekawym przypadkiem nie jest tu jak zakodować urządzenie, ale jak reprezenować jego lokalizację i połączenia pomiędzy urządzeniami.

Być w stanie opisać, jak przerwanie idzie ze slotu pci do rutera irq, do kontrolera przerwañ, do lokalnego apic, do cpu i jak równolegle idzie ze slotu pci do ioapic, do lokalnego apic, do cpi. I powiedzieć, że slot pci jest za mostkiem PCIX<->pci, To jest ciekawe zagadnienie. Zwłaszcza w strukturach danych, które przewidują mało specjalnych wypadków. Jesteśmy zamknięci w jądrze ze strukturą danych: struct pci_device, ale jeszcze nie skoñczyliśmy.

Nie sądzę zatem, że to w porządku opieprzać kogoś za używania 32bitowego punktu wejścia, chociaż zgadzam się z tym, że to jest dość wątpliwa rzecz w chwili obecnej.

Będzie dużym problemem utrzymanie tak wielkiego interfejsu stabilnym, a umożliwianie bootloaderom bezpośredniego używania go jest poronionym pomysłem. To nas zamknie wewnątrz tego interfejsu, albo spowoduje poważne problemy, gdy będziemy musieli wykonać w nim niezbędne zmiany.

Zamiast tego wszystkiego, wystarczy zauważyć, że najlepiej sobie radzić z tymi rzeczami podczas linkowania jądra. Jeśli powinien być obsługiwany PC-BIOS, zaznacz arch/i386/pcbios, możesz też wybrać inne platformy (zaznaczając na przykład arch/i386/linuxbios), które mają własny kod konfigurujący. Potem zlinkuj jądro z kodem odpowiadającym platformie na której działasz i gotowe.

Nie opieprzam nikogo; powiedziałem, że to zły pomysl. Teraz kodujesz tony założeñ, o tym co jądro potrzebuje od bootloadera, co może wkrótce przyprawić o ból głowy. Na przykład rzeczy, które opisujesz mogą się zdezaktualizować za 2 lata gdy na dobre wejdą HyperTransport, Infiniband i 3GIO. Teraz cierpisz bawiąc się z różnymi zgodnościami logicznymi aby wszystko zaczęło działać, co nie jest możliwe chyba, że dość często będziemy mieli poważne problemy.

Nie sądzę, aby to był dobry pomysł. Ten rodzaj danych należy do obrazu jądra, chociaż powinien być wyraźnie wyodrębniony wewnątrz drzewa jądra.

Pracuję nad skalowalnością schedulera. Zwłaszcza w przypadku używania Linuxa na większych maszynach (większa ilość CPU, SMP tylko na razie).

Zdaję sobię sprawę z większości obiekcji dotyczących zmian w schedulerze. Jednakże, wierzę że poniższa łata rozwiąże część problemów.

Łata implementuje scheduler wielokolejkowy (jedna kolejka na każdy CPU). W przeciwieñstwie do większości innych schedulerów wielokolejkowych, które polegają na skomplikowanych sposobach wyrównywania obciążenia, ten scheduler stara się podejmować globalne decyzje i emulować zachowanie bieżącego schedulera SMP.

Wydajność 'low-endowa' (niska ilość CPU i wątków) jest porównywalna do bieżącego schedulera. W przypadku wzrostu ilości CPU lub wątków, wydajność jest o wiele lepsza niż bieżącego schedulera. Wiećej informacji i porównania prędkości na http://lse.sourceforge.net/scheduling/ (wykład z Ottawa Linux Symphosium).

Chciałbym usłyszeć komentarze, czy jest to dobry kierunek w drodze do usunięcia ograniczeñ skalowalności w bieżącym schedulerze. Jasne jest, że domyślny scheduler w jądrze powinien działać dobrze w większości przypadków. Moim zdaniem załączona implementacja schedulera uzyskuje to przez swoją skalowalność wraz z liczbą procesorów w systemie.

Wydaje mi się że kod wyglądał rozsądnie, ale tak ciężko czyta się łatę, że nie jestem w stanie poczynić żadnych naprawdę inteligentnych komentarzy.

Jedyną rzeczą która wyglądała naprawdę brzydko była kolejka czasu rzeczywistego. Czy ona _naprawdę_ musi być zrobiona w ten sposób?

Czy mogę wyjaśnić co sugeruje Linus? Zamiast:

#ifdef CONFIG_SMP

.. użycie nr_running() ..

#else

.. użycie nr_running ..

#endif

lepiej napisać:

inline int nr_running(void)
{
#ifdef CONFIG_SMP

int i = 0, tot=nt_running(REALTIME_RQ);
while (i < smp_num_cpus) {

tot += nt_running(cpu_logical_map(i++));

}
return(tot);

#else

return nr_running;

#endif
}

Następnie należy zobaczyć czy można się pozbyć #ifdef'ów również z tego fragmentu. (Jęśliby okazało się to zbyt trudne - cóż, przynajmniej ilość #ifdef'ów została zmniejszona).

Jeszcze lepiej mieć po prostu (w pliku nagłówkowym)

#ifdef CONFIG_SMP
inline int nr_running(void)
{

...

}
.. inne przypadki SMP ..
#else
#define nr_running() (__nr_running)
.. inne przypadki UP ..
#endif

jeśli nie możesz zrobić wydajnych funkcji działających w obu scenariuszach.

Nie, nie zachęcamy do robienia tego wszędzie. Ale powinno się probować.

Obecność #ifdef'ów na zewnątrz kodu ma dwie zalety:

• czyni to kod o wiele czytelniejszym i nie rodziela za bardzo rzeczy
• musisz wybrać interfejsy abstrakcji bardziej starannie, co prowadzi do tworzenia lepszego kodu.

Abstrakcja jest miła - _zwłaszcza_ gdy masz kompilator który widzi poprzez abstrakcję i może generować kod jakby jej nie było.

Przebieg #1 przepustowość 5.88569 MB/sec 2.4.8-pre8
Przebieg #2 przepustowość 5.95613 MB/sec 2.4.8-pre8
Przebieg #3 przepustowość 5.8547 MB/sec 2.4.8-pre8

Przebieg #4 przepustowość 7.84171 MB/sec 2.4.7-ac10
Przebieg #5 przepustowość 7.68447 MB/sec 2.4.7-ac10
Przebieg #6 przepustowość 7.85119 MB/sec 2.4.7-ac10

Przebieg #7 przepustowość 10.2184 MB/sec 2.4.7
Przebieg #8 przepustowość 10.0105 MB/sec 2.4.7
Przebieg #9 przepustowość 10.0215 MB/sec 2.4.7

Zauważ, że dbench pokazuje najlepsze wyniki, gdy nie ma rzeczywistego zapisu na dysk: cały test można całkowicie zoptymalizować. Tak więc, najlepsze wyniki będą gdy (a) zatrzymasz kflushd oraz (b) ustawisz dużą wartość flagi dirty.

Czy wyniki się jakkolwiek zmieniają jeśli zrobisz coś takiego:

killall -STOP kupdated
echo 80 64 64 256 500 6000 90 > /proc/sys/vm/bdflush

co sprawi, że dane na dysk będą rzadziej zapisywane? (Te instrukcje będą zatrzymywać flushowanie co 5 sekund oraz będą trzymały wartości "brudnych" i-węzłów na poziomie 80/90% zamiast domyślnych 30/60%)

W szczególności balansowanie liczby "brudnych" i-węzłów było wcześniej wykonywane naprawdę źle, ale to zostało już poprawione. Podejrzewam, że wartości bdflush były dostosowane do źle działającego przypadku i mogły być zbyt restrykcyjnie ustawione jak dla dbench...

Ponownie uruchomiłem dbench z powyższymi ustawieniami. Oto rezultaty: (Takie same warunki, jak we wcześniejszych testach). No a teraz pora iść do pracy.

Przebieg #1 przepustowość 12.7943 MB/sec 2.4.8-pre8
Przebieg #2 przepustowość 12.667 MB/sec 2.4.8-pre8
Przebieg #3 przepustowość 12.7091 MB/sec 2.4.8-pre8

Przebieg #4 przepustowość 13.7765 MB/sec 2.4.7
Przebieg #5 przepustowość 13.9632 MB/sec 2.4.7
Przebieg #6 przepustowość 13.9318 MB/sec 2.4.7

No, wygląda lepiej

Problem z dbench jest taki, że nie ma bata żeby zoptymalizować system dla niego w sposób ogólny, bo to taki dziadowski test jest.

Na przykład, czekanie do samego koñca na rzeczywiste zapisanie na dysku jest zdecydowanie najlepszym ustawieniem dla dbencha, ale zupełnie bezużytecznym w praktyce.

Podejrzewam, że do optymalnych wyników dbencha będziemy zawsze potrzebować, aby administrator wykonał te obrzydliwe sztuczki, ale jednoczeście strasznie mi się nie podoba konieczność ich wykonywania i chciałbym aby domyślne ustawienia wypadały w testach dość dobrze.

Przykładowo, zabijanie kupdated nie jest zbyt "sensowne". Ale podejrzewam także, że skoro już balansowanie "brudnych" i-węzłów działa w miarę, to "rozpoczęcie zapisywania, gdy 30% jest pełne" jest ciut za wcześnie.

Tak więc zamiast podziału 30/60% (pierwsza wartość to "kiedy zacząć zapisywać na dysk", a druga - "kiedy aktywnie zacząć czekać na to"), podział 50/75% może być całkiem sensownym dla przeciętnego obciążenia, przy okazji poprawiając nieco wyniki dbencha.

Czy ty (albo ktoś inny) chciałbyś się jeszcze trochę pobawić i przypatrzyć się więcej zarówno testom dbencha, jak i interaktywnym wrażeniom?

Ogólnie

echo x 64 64 256 500 3000 y > /proc/sys/vm/bdflush

ustawi "start zapisu na dysk" na 'x'%, a "start synchronicznego czekania" na 'y'% (i zrestartuj kupdated za pomocą "killall -CONT kupdated"). Ciekawie będzie usłyszeć gdzie leży złoty środek.

Uruchomiłem dbench 32 dwadzieścia osiem razy. Wyniki poniżej. Jednostki przepustowość w MB/s, tak jak w dbench. W wierszach jest pierwsza wartość: "rozpocznij zapisywanie". W kolumnach jest druga wartość: "rozpocznij synchroniczne oczekiwanie". Na przykład pole w lewym dolnym rogu tabelu zostało uzyskane po wydaniu polecenia echo 30 64 64 256 500 6000 60 > /proc/sys/vm/bdflush

	60	70	80	90
90	8.693	8.690	8.853	8.875
80	8.822	8.724	8.703	8.910
70	8.558	8.557	8.785	8.420
60	8.194	8.141	8.006	7.847
50	6.662	6.738	6.904	6.892
40	6.347	6.252	6.380	6.274
30	5.687	5.802	6.209	5.898

Nie mam dostatecznie dużego zbioru wyników do "interaktywnych odczuć", poza tym, że nigdy nie jest dobrze przy dużym obciążeniu maszyny. W trakcie weekendu postaram się jeszcze pobawić trochę dbenchem, aby uzyskać jakieś użyteczne wyniki.

Jeśli ktoś chce cokolwiek z rzeczy dotyczących systemu plików Netware'a dla NT lub Linuxa najlepiej żeby je zdobył teraz. Nadal będę pracował nad Linuxowymi zmieniaczami taśm , SCI itd., ale rzeczy NetWare'owe dostępne będą tylko do soboty, kiedy to serwery zawierające technologię specyficzną dla NetWare lub Novella zostaną usunięte. Pierwszego września 2001r. zakładamy sprawę sądową przeciwko Novellowi, aby pozbyć się zobowiązañ wobec nieistniejącej firmy i nas samych, które to zobowiązania wiszą nad nami od czterech lat.

Strona nadal będzie w sieci, ale wiele się zmieni. Ściągać można z www.timpanogas.org i ftp.timpanogas.org. Jeśli chcesz czegokolwiek, teraz jest czas aby to dostać. Ta strona nadal będzie się zajmowała kodem SCI.

Kiedy pojawi się nowa strona, niektórzy moga się zdziwić, ponieważ nasz firma oprócz oprogramowania prowadzi również laboratorium genetyczne. Na stronie będzie można znaleźc wyniki naszych manipulacji genetycznych na probiscidea i mesembrecanthea. Wyizolowaliśmy lekarstwo na artretyzm (nie leczenie, trwałe lekarstwo) z roślin amerykañskich banków nasion i przeprowadziliśmy podział genów i indukcję polyploidalną z wieloma z nich. Będziemy kontynować pracę nad linuxowym SCI i w innych obszarach.

Dostępna jest wersja 1.1 systemu budowania jądra dla serii 2.5 (kbuild 2.5). http://sourceforge.net/projects/kbuild/, Pakiet kbuild-2.5, bierzcie wersję 1.1.

http://marc.theaimsgroup.com/?l=linux-kernel&m=99725412902968&w=2 zawiera informację i pierwotnej wersji.

Zmiany od wersji 1.

• Uaktualnienie do jądra 2.4.8. Wart zobaczyć jak prosty jest teraz Makefile DRM.
• Poprawiony wyścig przy współbieżnym budowaniu gównego makefile, gdy nie wszystkie obiekty były rozpoznane jako cele ani nie były rozpoznane jako kandydaci do rekompilacji.
• Zastąpnienie ręcznie napisanych reguł przez side_effect().
• Udokumentowanie celów kbuild i C według konwencji asemblerowaj. Jak zwykle Documentation/kbuild/kbuild-2.5.txt jest twoim przyjacielem.
• Usunięcie polecenia assembler(). kbuild teraz działa, gdy źródłem jest .c albo .S bez potrzeby interwencji człowieka.
• Jeśli bezpośrednio budujesz foo.i albo foo.s, kbuild automatycznie wygeneruje niezbędne reguły z identycznymi flagami, jak dla odpowiadających im plików .o. Użyteczne do debugowania preprocesora czy problemów z asemblerem, szczególnie, gdy gcc -save-temps nie działa z wieloma katalogami.
• Standardowe generowanie plików .s z .c, gdzie plik .s jest wymagany przez reguły make'a. To obejmuje śledzenie zależności pliku .c

Ostatnia zmiana pozwoliła mi rozwiązać odwieczny problem z kbuild 2.4. Każda architektura ma swój asembler, który wymaga wyrówniania pól w strukturach C, czy też mapowania nazw C na liczby. Asembler nie może włączyć definicji C, więc potrzebujemy mapowania z konstrukcji C na numery asemblera. Każda architektura rozwiązuje ten problem w inny sposób, żadna z tych metod nie jest w 100% dokładna ani pewna.

i386 na sztywno zapisuje te wyrówniania w kodzie asemblera i ma nadzieję, że definicja struktur się nigdy nie zmieni.

Alpha używa programów w C, który generuje tekst dla asemblera. Ale to nie działa przy kros-kompilacji, ponieważ to podejście zakłada, że HOSTCC == CC.

Cris generuje kawałek kodu asemblera z C i następnie wykorzystuje .include zamiast #include, z jakimś śmiesznym wyborem opcji.

Mips, parisc, ppc i sparc generują kod asemblera, a poźniej wyciągają i przeformatowywują linie z tego kodu. To działa zarówno przy kompilacji lokalnej, jak i przy kros-kompilacji i to już jest prawie tak, jak powinno się robić. Ale są tu jeszcze problemy, o których poniżej.

IA64 w 2.4 jest wyjątkowo obrzydliwe. Używa innych metod w natywnym trybie i przy kros-kompilacji, podczas gdy ta druga metoda wystarczyła by w zupełności. Dostarcza kopię wygenerowanego asm/offsets.h, która jest całkowicie nieelastyczna, ponieważ prawdziwe offsets.h zależy od konfiguracji użytkownika. Co gorsza, offsets.h jest włączane w processor.h i ptrace.h w ia64, więc wpływa na prawie każdy plik C.

Żadna z powyższych metod nie sprawdza zależności. PPC próbuje, ale jest to definiowane ręcznie i jest niekompletne, a żadna inna architektura nie podejmuje nawet próby. Wszystkie architektury zakładają, że użytkownik wykona make dep po jakichkolwiek zmianach w konfigu, które mają wpływ na wyrównania w asemblerze. Jeśli użytkownik zapomni uruchomic make dep i wartośći asemblera i C nie pasują - to robi się kaszana.

kbuild 2.5 ma zaimplementowane rozwiązanie, które działa we wszystkich trybach, jest standardowe dla wszystkich architektur i automatycznie śledzi zmiany zależności. Nie ma więcej miejsca na ludzkie błędy.

Tia. Jak na razie nowy sterownik, który Linus wziął od innej osoby niż poprzedni, psuje

• SMP
• Niektóre mixery
• Współpracę niektórych kart na UP
• Dzwięk surround (trzeszczy)

także uważam, że Linus powinien zrobić jedyną słuszną rzecz - cofnąć zmiany. Wycofuję nowy sterownik z -ac. Z moich trzech skrzynek jedna szumi, jedna zawiesza się przy SMP, jedna działa.

Cóż, zauważ że _stary_ sterownik również nie jest stabilny i nie działa na wszystkich maszynach. Jest naprawdę źle gdziekolwiek by się nie odwrócić.

Jeśli stary sterownik działałby, usuwanie go byłoby bezmózgowiem. Jednakże stary sterownik _również_ niektórym nie działą - ale nie odzywają się, ponieważ stary sterownik zawsze był zepsuty.

Mamy więc sytuację w której nowy sterownik działa lepiej na jednych maszynach, stary działa lepiej na innych. Oczywiście stary sterownik nigdy nie będzie naprawiony (było na to kilka lat czasu), więc stary sterownik jest znany jako całkowicie zepsuty. Nowy sterownik w tej kwestii ma znak zapytania.

A więc raczej dam szansę nowemu sterownikowi i zobaczę czy ktoś może go naprawić. Na przykład, oops który zgłaszają ludzie jest _chyba_ spowodowany inicjacją taskletu przed zainicjowaniem wszystkich struktur danych na których polega tasklet. Prawdopodobnie przesunięciu obydwu "tasklet_init()" w dół o dwie linie naprawi to.

Wyjeżdżam do Finlandii na tydzieñ+ i nie będę w tym czasie czytał poczty i newsgrup. Umieszczam 2.4.9 na ftp.kernel.org i sugeruję aby ludzie wypróbowali go i przedyskutowali na liście pocztowej, ale NIE wysyłali emaili do mnie. Będę ciekaw problemów po powrocie, ale nie za bardzo mam ochotę na tysiące wiadomości czekających na mnie.

Dodatkowo, dostaję _dużo_ łatek, więc jeśli twoja się jeszcze nie ukazała, to dlatego że mam ich zbyt dużo. Bez strachu, zawsze jest jutro. Tylko w tym wypadku będzie to "tydzieñ lub dwa".

• David Miller: aktualizacja sparc'a, poprawki FAT, poprawka kompilacji btaudio
• David Gibson: aktualizacja sterownika Orinoco
• Kevin Fleming: więcej dysków których nie lubi kontroler HPT
• David Miller: poprawki "min()/max()". Rozumie znaki i rozmiary.
• Jens Axboe: aktualizacja CD
• Trond Myklebust: poprawki w kodzie NFS.
• Mark Hemment: wyczyszczenie operacji na HIGHMEM
• Jes Sorensen: użycie "unsigned long" dla flag w różnych sterownikach

Historycznie, aby móc zainstalować jądro 0.01, musisz mieć pełną dystrybucję minix-386 - to był jedyny sposób aby mieć system plików, skopiować potrzebne pliki itp.

Szczerze mówiąc to również dla mnie minęło dziesięć lat, więc nie pamiętam wszystkich szczegółów.

Najprawdopodobniej i tak nie masz dostępu do minix-386, więc podejrzewam, że to co _powinieneś_ zrobić to spróbować użyć nowszej wersji Linuksa by zbutować to jądro. Potrzebujesz też naprawde starego kompilatora by skompilować Linuksa-0.01 - sądzę, że wymaga on gcc-1.40 lub czegoś w okolicach. Po prostu nie skompiluje się nowszym.

Mimo wszystko to może być zrobione. Chociaż nie robiłem tego osobiście od dziesięciu lat i nigdy z Linuksa. Podejrzewam, że najlepiej Ci bedzie próbować dyskutować jak to zrobić na kernel-list lub podobnych, nie wahaj się cytować tego emaila jako początku takiej dyskusji.

jądro 0.01 powstało sporo wcześniej nim zacząłem się zajmować Linuksem, więc nie mogę Ci z nim pomóc. To co moge zasugerować to zainstalowanie i uruchomienie wersji Redhata. Instalator znajdzie wirtualną maszynę (VM), która pozwoli Ci zainstalować drugiego linuksa, którego będziesz mógł uruchomić z sesji VM. Używaj go jako środowiska do nauki. Nigdy tego nie robiłem, może inni będą mieli lepsze komentarze na ten temat.

Myślę, że:

Po pierwsze; jądro jest stale uaktualniane. Najlepszym sposobem na uzyskanie pomocy w czymkolwiek jest praca z aktualnymi źródłami.

Po drugie; wiele narzędzi włączonych do Linuksa zostało znacznie poprawionych ostatnio. Używanie tych narzędzi powinno zaowocować lepszym doświadczeniem.

Po trzecie; Jakość jądra stale się poprawia. Na przykładzie takiego poprawionego jądra można dobrze nauczyć się systemów operacyjnych.

Weź parę wersji wyżej, może już 0.02, jeśli chcesz mieć nadzieję na uruchomienie kompilatora na tym systemie. Będziesz potrzebował conajmniej 4MB RAM dla kompilacji, ponieważ wczesne jądra nie obsługiwały partycji wymiany.

Minix-386 to zhakowany Minix. Minix jest systemem operacyjnym, stworzonym w celach edukacyjnych, na 8088, który od niedawna jest wolny. Jest cały zbiór łat, które pozwalają na dodanie obsługi 386. Zdobądź i uruchom Miniksa, połataj go, a potem skompiluj Linuksa.

Spróbuj tak:

System plików Miniksa ma najwyżej 64 MB. Stwórz dla niego partycję, partycję wymiany oraz jedną dla nowszej dystrybucji Linuksa. Ten przed-Slackware może być dobry: http://www.ibiblio.org/pub/Linux/distributions/MCC/2.0+/

Um, naprawdę nie chcesz kompilować gcc na 386. Być może będziesz musiał skompilować pośrednie wersje, ponieważ stare gcc może się nie kompilować najnowszym gcc. Być może masz lub możesz pożyczyć nowocześniejszą maszynę do samej kompilacji.

Znalezienie dodatków takich jak libc oraz shell, będzie trudne.

Być może będziesz potrzebował bootloadera "shoelace". Powinieneś móc uruchomić go z LILO.

Kto usunął to ostatnio ze sterowników w 2.4.x i dlaczego?

Zmieniałem sobie parę rzeczy i przez przypadek parę razy zepsułem mój firmware i aby mieć go z powrotem musiałem sięgnąć do starszych jąder żeby z powrotem mieć działającą moją qlogic, kartę FC.

Usuwanie firmware nie ma sensu, jeśli firmware jest niewłaściwy z jakiegoś powodu, trzeba go po prostu poprawić.

może być różnie z uzyskaniem tego firmware.

Przejrzałem sterownik QLogic v4.27 z ich strony internetowej i naprawdę jest tam włączony firmware z liczencją GPL.

Dave, jeśli chce Ci się z tym bawić i wciskać to w sterownik qlogicfc.c będziesz przynajmniej miał coś co w pewien sposób będzie na razie działać (modulo wszystkie inne problemy z tym sterownikiem).

http://www.qlogic.com/bbs-html/csg_web/
adapter_pages/driver_pages/22xx/22linux.html

Mają tam głupią licencję 'przeczytaj i zgódź się' na początku tej strony jeśli wchodzisz przez oficjalne qlogic.com, jednakże jeśli kod tam zawarty jest GPL to zakładam, że jest GPL.

Trochę informacji i komentarzy:

Prawa autorskie "BSD" w f/w które mam z QLogic są tam tylko dlatego, że Theo Deraadt straszył, że wyciągnie QLogic z OpenBSD 2.7. Błagałem ich przez ponad rok żeby zrobili *coś*. Powinienem uzyskać licencję BSD bez klauzuli o ogłaszaniu, ale, no tak.....

Żeby zrozumieć co się dzieje, najlepiej jest załadować fimware do SRAMu karty. W ten sposób *wiadomo*, że rozumie to coś tam (takie jak na przykład SCCLUN). QLogic produkuje firmware w różnych smakach z tym samym numerem wersji i trudno jest wydedukować samowystarczalność albo bezpieczeñstwo firmware'u.

Mówiąc to wierzę, że możliwe *jest* w środowisku bez BIOS wyciągnięcie firmware'u z flash romu - trzeba tylko ręcznie pokombinować z rejestrami, które normalnie są dotykane tylko przez firmware; myślę, że *jest* technicznie możliwe wyciągnięcie zawartości flasha do pamięci systemowej, odgadnięcie gdzie jest 'rezydujący' obraz firmware w tym wszystkim i przegrać *to* do SRAM i zrestartować. To stawia Cię w miejscu, w którym byłeś poprzednio.

IMO, najlepszą rzeczą jaką można zrobić jest zrobienie ładowalnego modułu ispfw, który znika po załadowaniu SRAM. Zacząłem iść tą drogą w FreeBSD (jest oddzielny moduł ispfw) - która będzie naprawdę użyteczna gdy kiedykolwiek pojawi się żądanie pamięci modułów we FreeBSD :-). Ma to szczególne znaczenie dla mojego sterownika, ponieważ obsługuje on 1020 (SBus (tak dla NetBSD/OpenBSD, jeszcze nie dla Linuksa) && PCI), 1080/1280 Ultra2, 12160 Ultra3, 2100 FC, 2200FC i 2300FC (w przyszłym tygodniu)- można skoñczyć z absurdalną liczbą obrazów firmware'ów.

Jestem pewien, że coś podobnego może być zrobione dla Linuksa.

Alan- możesz rozmawiać z QLogic- świetnie. Mi się z nimi rozmawia coraz trudniej. Jeśli uda Ci się przekonać ich aby wypuścili 2100 i 2200 i 2300 f/w na GPL dla Linuka- wspaniale.

W BitKeeper, którego jeszcze nie skoñczyliśmy, Linus zażyczył sobie dwóch reczy. Jedną jest usunięcie plików kontroli wersji z drzewa roboczego, a drugą rozbicie drzewa na logiczne części (nazywamy je zbiorami plików), tak by można było łatwo wybierać które łatki są tak naprawdę potrzebne we własnym jądrze.

Jakiś czas temu Linus pingał mnie o to, zrobiliśmy pewne postępy w pracy, ale to co chcemy zrobić nie jest jeszcze gotowe. Gdy tylko to skoñczymy damy to Linusowi, żeby sobie pooglądał i zobaczymy co o tym myśli.

W międzyczasie ludzie od PPC utrzymyją czysty kod Linuksa w BK, możesz go obejrzeć pod adresem http://ppc.bkbits.net a Ted Tso ostatnio zrobił całkiem miły import różnych wersji jądra. Muszę jeszcze popracować z ludźmi od PPC i Tedem tak by uzyskać jedną wersję kodu; nie jest to łatwe zadanie, bo kod dla PPC ma wiele zmian, a drzewo przygotowane przez Teda jest znacznie milsze, wykonał on mnóstwo pracy aby zachować komentarze i znaczniki czasowe.

Aby uniknąć jeszcze-jednej-wojny-o-BK (yet-another-BK-flamewar), nie mówię że Linus będzie lub nie będzie używał BitKeepera, mówię tylko, że robimy zmiany, których chciał i jeśli je zrobimy to on zobaczy czy jest to dla niego wystarczająco dobre. Powiedziałbym, że trochę odpuścił ze swojego pierwotnego stanowiska mówiącego, że ,,będę używał BitKeepera jeśli bedzie najlepszy'', bo spytałem go czy to znaczyło to co ja pomyślałem, że on pomyślał, czyli ,,nie jest fizycznie możliwe zrobienie tego lepiej'' i zestawiłem to z ',,jest lepsze od wszystkiego innego takiego gówna''. Chyba się zgodziliśmy że raczej chodzi o #2, a niekoniecznie o #1 (co jest dobrą rzeczą, bo w tym tempie będziemy najlepsi kiedyś w tym wieku, a stanie się to wtedy kiedy będę chciał to nazwać najlepszym :-)

Piękny trace. Przejąłeś przerwanie w trakcie wołania PnPBIOS i twoja maszyna eksplodowała. Zrób mi przysługę -

Zmieñ semafor w drivers/pnp/pnp_bios.c na spinlock_irqsave i __cli/ spin_unlock_irqrestore. Sprawdź czy wtedy pady się skoñczą.

Dobra, wróciłem z Finlandii i jest już 2.4.10-pre1 na kernel.org. Załączyłem Changelog..

Najbardziej zasługującą na uwagę rzeczą (przy odpowiednim obciążeniu) jest prawdopodobnie jednolinijkowa zmiana Daniela pozwalająca uniknąć błędów w trakcie wymiany (swapping).

• Jeff Hartmann: poprawki w DRM AGP/alpha
• Ben LaHaise: optymalizacja highmem pagecopy/clear użytkownika
• Vojtech Pavlik: aktualizacja sterownika VIA IDE
• Herbert Xu: cramfs działające ze stronami HIGHMEM
• David Fennell: poprawienie wykrywania wielkości ramu awe32
• Istvan Varadi: poprawienie błedu w nazwach plików umsdos EMD
• Keith Owens: działające min/max także dla wskaźników
• Jan Kara: naprawienie inicjalizacji quoty
• Brad Hards: aktualizacja sterownika Kaweth USB (włączenie i poprawka kolejności bajtów)
• Ralf Baechle: aktualizacje MIPS
• David Gibson: aktualizacja sterownika
• Rogier Wolff: obsługa sterownika ATM multi-phy
• Daniel Phillips: poprawki w czytaniu stron w trakcie wymiany - uniknięcie śmiecenia przez obsługę wymiany.