Kernel Traffic #130 For 13 Aug 2001

W przyszły weekend wyjeżdżam na tygodniowe wakacje, więc Kernel Traffic najprawdopodobniej nie będzie się ukazywał do koñca sierpnia. Sorry ludkowie. Wierzcie bądź nie, ale będzie to mój pierwszy prawdziwy odpoczynek od KT od jego zarania w styczniu 1999.

There were 534 different contributors. 267 posted more than once. 145 posted last week too.

Moja karta sieciowa przestała współpracować ze sterownikami tulipa włączonymi do jądra >= 2.4.4 oraz z ich wersjami rozwojowymi z sourceforge.net.

Wygląda na to, że sterownik niepoprawnie ustawia kartę w trybie full duplex i nie umiem tego zmienić przy pomocy nowego makra MODULE_PARM.

Teraz używam stabilnego sterownika 0.9.14 z sourceforge.net, który działa poprawnie.

Joshua Schmidlkofer dodał, że także miał problemy ze sterownikiem tulipa na kilku kartach SMC, opartych na chipsecie DEC. Jeff Garzik odpowiedział: "W chwili obecnej są pewne problemy ze starymi chipsetami 21041, obejmują one SMC i kilka innych kart. Możecie używać wersji 0.9.14 z http://sf.net/projects/tulip/ dopóki nie wymyślę jak ten problem rozwiązać." Michal Jaegermanm przedstawił swoje doświadczenia: "Już kilka razy zgłaszałem problem z kartą DS21143 Tulipa w wersji 65, która nie jest zbyt stara, i sterownikami nowszymi niż 0.9.14, i nie dostałem nawet pół linijki z potwierdzeniem, ani potwierdzeniem poprawek. Wysłałem także wyjście mii-diag z karty w działającym i niedziałającym stanie." Włączył się jeszcze Patrick Cole: "Moja karta 21041 również nie działa ze sterownikiem tulipa dołączanym do jąder 2.4. Natomiast słyszałem, że sterownik de4x5 działa dobrze."

Nieco później, Chris Friesen spytał Thomasa, czym wersja z Sourceforge różni się od tej na scyld.com. Jeff wyjaśnił: "To są całkiem różne wersje, mimo że mają wspólny korzeñ." Ben Greear jeszcze dodał: "Becker (Scyld) ostatnio nawet poprawił tak swoje sterowniki, aby kompilowały się pod jądrem 2.4, ale mimo to, są one ewidentnie jeszcze w niestabilnej fazie rozwoju, jak dla jąder 2.4. Wygląda na to, że są próby utrzymania tej samej funkcjonalności, ale różnice architekturalne pomiędzy sterownikami są duże..."

Richard Gooch wysłał łatkę, dającą wsparcie dla mniej więcej 2144 dysków SCSI i poprosił o przetestowanie. Wyjaśnił, że w kodzie znajdują się rozwiązania dla trzech scenariuszy: mniej niż 16 dysków SCSI, pomiędzy 17 a 128 dysków, oraz więcej niż 128 dysków SCSI. Poprosił o raporty dla wszystkich trzech scenariuszy i przypomniał, żeby uważać na swoje dane. Evan Felix odpisał " Miło mi to zobaczyć. Sam ostatnio zwiększyłem ilość głównych numerów urządzeñ z 8 do 32 poprzez rozszerzenie drugiego zakresu od 65-71 do 65-95. To rozwiązanie wdepnęło w inne główne numery urządzeñ, macierz COMPAQ SMART, interfejsy IDE od 6. do 9. itd. Nie sądzę, żeby to było dobre rozwiązanie dla głównego jądra, więc używam go jedynie u siebie. Cieszę się, że ktoś z większym doświadczeniem zabiera się za to. " Dodał " Napisałem łatkę do Ogólnego Sterownika SCSI (SCSI Generic Driver), aby ten używał devfs do zwiększenia ilości pobocznych numerów urządzeñ poza ograniczenie do 256. Użyje tak wielu głównych/pobocznych numerów, ile dostanie od devfs. Łatkę tę można znaleźć na oficjalnej stronie sg: http://gear.torque.net/sg/ jako eksperymentalny sterownik sg3120df. " Richard odpowiedział " Tak, Doug mówił mi o tym na OLS. Niestety dodałeś jeszcze jedną pętlę wyszukującą w handlerze BH. Nie jest to jednak twoja wina, ponieważ warstwa pośrednia SCSI nie ma wskaźnika od struktury żądania SCSI do struktury wysokopoziomowego sterownika. Naciskałem na Douga aby wysłał Linusowi łatkę, która to zmienia. " Gdzie indziej, Eric Youngdale odpowiedział na pierwszy list Richarda "W pewnym momencie serii 2.5 chciałbym zrobić trochę poważnych operacji chirurgicznych na strukturach SD - głównie aby usunąć zależność kolejności ładowania i wyeliminować potrzebę CONFIG_SD_EXTRA. Wierzę, że część pracy którą Jens zaczął w warstwie urządzenia blk znacznie ułatwi wsparcie dla bardzo dużej ilości dysków. "

Nadav Har'El słyszał, że 2.2 wspiera SMP tylko na systemach Intelowych, a na AMD już nie. Zacytował stare SMP HOWTO mówiące "Intel jest właścicielem technologii APIC SMP, i dopóki firma nie wykupi licencji od Intela, nie może tego używać. W tej chwili nie ma firm, które by to zrobiły. (Może się to oczywiście zmienić w przyszłości) Dla Twojej Informacji: Zarówno Cyrix jak i AMD wspierają nie-zamknięty standard OpenPIC SMP, ale nie ma płyt głównych, na których miałby zastosowanie." Johannes Erdfelt odpowiedział, że nowsze jądra 2.2, jak i wszystkie 2.4, wspierają SMP na systemach AMD. Dodał, że te systemy używają technologii APIC SMP Intela.

Gdzie indziej, Joel Jaeggli wspomniał, że kombinacja procesora AMD i płyty głównej pod Athlona będzie działać dobrze, a 2.4 wspiera większą liczbę konfiguracji sprzętowych. Ale Alan Cox zauważył, że "Athlon SMP nie zawsze działa z 2.2. Kilkanaście osób zgłosiło problemy i przysłało łaty do 2.2.20pre, które poprawiały ich problemy wprowadzając inne, więc zostały odrzucone. 2.4 wydaje się pracować poprawnie." Johannes Erdfelt odpowiedział, "Wysyłam ci nową poprawkę, która rozwiązuje problem." Wysłał łatę, a Alan odpowiedział, "Wygląda na to, że przeoczyłem ją za pierwszym razem - dziękuję, zastosuję ją. "

Czy nie byłeś nigdy sfrustrowany faktem, że update firmware'u zawartego w pamięci flash wymaga zainstalowania zamkniętego oprogramowania? Jest rozwiązanie tego problemu: sterownik w jądrze do różnych rodzajów (Flash)BIOSów dostępnych obecnie na sprzęcie x86 i Alpha AXP.

To /dev/bios - i najnowsza wersja 0.3.1 została właśnie wydana.

Znane są następujący BIOSy

* System BIOS (znajduje się pod adresem 0xe0000)
* sprzęt graficzny (np. VGA pod 0xc0000)
* kontrolery SCSI
* karty sieciowe z 'BOOT ROM' * ...

O ile kiedyś te BIOSy używały pamięci ROM lub EPROM (nie mogły zostać uaktualnione bez otwierania komputera), to dzisiejsze komputery PC mają tzw. FLASH BIOSy, które mogą być uaktualnianie w prosty sposób za pomocą programu. Ten sterownik to próba dodania do Linuksa możliwości czytania i zapisywania flash rom'ów.

Co nowego w 0.3.1?

* kompiluje się i działa z jądrami 2.4
* przepisanie procedury wykrywania kości flash
* teraz zawsze używa ioremap()
* kości flash większe niż 128k powinny działać bezproblemowo
* wsparcie dla nowszych chipsetów VIA

Devbios można ściągnąć z http://www.freiburg.linux.de/~stepan/bios/

Pamiętaj, żeby PRZECZYTAĆ README ;-). Póki ładujesz moduł bez żadnych parametrów, sterownik jest w trybie tylko-do-odczytu i nie może namieszać w twoim systemie, więc nie krępuj się próbować i przysyłać mi jakichkolwiek wyników testów.

Rajeev Bector spytał, czy jest jakiś sposób aby znaleźć nazwę modułu jądra dysponując jedynie jego adresem. Keith Owens odparł: "Kai Germaschewski parę dni temu wysłał na l-k łatę z kodem, który potrzebujesz. Przeszukaj archiwum l-k pod kątem ciągu 'wyłączenie wstecznego śledzenia modułów' (ang. 'disable module backtraces')." Rajeev nie mógł znaleźć tego w archiwach, więc Keith podał mu odnośnik.

Projekt kernel build z dumą ogłasza pierwszą wersję narzędzi do kompilacji jądra dla jąder 2.5 (kbuild 2.5). http://sourceforge.net/projects/kbuild/, pakiet kbuild-2.5, do ściągnięcia wersja 1.

Jest to zupełna zmiana projektu i kompletne przepisanie systemu kompilacji jądra. Pierwotnie był on przewidziany dla jąder 2.5, ale może być także używany z jądrami 2.4, właściwie to był rozwijany na jądrze 2.4. Tylko kilka plików z kbuild 2.4 zostało zmienionych przez naszą łatkę i te zmiany są takie, że można wciąż kompilować 2.4 przy użyciu kbuild, nawet gdy zainstalowana jest łatka kbuild 2.5.

Cechy kbuild 2.5. Aby uzyskać pełniejszy opis ściągnij łatę i przeczytaj Documentation/kbuild/kbuild-2.5.txt.

Pozwala używać oddzielnych katalogów dla źródeł i binariów. Możesz skompilować wiele wersji jądra z jednej kopii źródeł, używając rozłącznych katalogów dla binariów i konfigurując oddzielnie każdą wersję. Możesz nawet skompilować równolegle te same źródła dla różnych architektur.

Pozwala używać wspólnych katalogów dla źródeł i binariów. Domyślnie jest to tak jak w kbuild 2.4, czyli używane są te same katalogi dla źródeł jak i dla binariów. Nawet w tym trybie kbuild 2.5 prawie wszystkie pliki źródłowe traktuje tak jakby były tylko do odczytu, nie ma więcej kombinowania z oznaczaniem czasu dla plików z rozszerzeniem .h. Wyjątkiem są pliki generowane w czasie wykonywania, które niepotrzebnie zostały częścią tar balla z jądrem. Będę dosyłał łaty, które usuwają te pliki z tar balla z 2.4. Oczywiście w tym trybie można skompilować na raz tylko jedno jądro.

Wspiera wiele katalogów ze źródłami. Ponieważ rozwój jądra stał się bardziej rozproszony to coraz trudniejszym zadaniem dla zewnętrznych jego developerów jest takie przystosowywanie kodu, by kompilował się z właściwymi źródłami jądra i z właściwymi opcjami. Obsługa wielu katalogów ze źródłami (shadow trees), zewnętrzny kod może być traktowany jak część głównego drzewa źródeł jądra. To jest użyteczne przy rozwijaniu nowych sterowników, nowych systemów plików, testowaniu zamienników dla istniejących sterowników, nakładaniu łatek specyficznych dla architektury na główne jądro itp.

Jeden ogólny Makefile dla całego jądra. Zamiast wykonywać make rekursywnie zstępująco przez wszystkie katalogi kodu źródłowego kbuild 2.5 zbiera fragmenty makefile ze wszystkich katalogów, sprawdza je i łączy w pojedynczy globalny makefile. Make działa lepiej gdy dostarczy mu się pełny obraz. W szczególności zmiana w jednym pliku albo opcji konfiguracyjnej powoduje teraz tylko przekompilowanie i ponowne scalenie jedynie obiektów, których dotyczyła, nic więcej nie podlega ponownej kompilacji.

Wsparcie dla CML2. Łata udostępniona na sourceforge'u używa kodu Configuration Mini Language 1 (CML1) z kbuild 2.4. Można wybrać sobie wsparcie CML1 lub dla CML2, ale by użyć CML2 trzeba pobrać aktualne pozycje z CML2 ze strony CML2 Erica Raymonda, http://www.tuxedo.org/~esr/kbuild/. Oczekujemy, że jądra 2.5 będą miały obsługę jedynie CML2, więc radzimy testować CML2 teraz, kiedy obie wersje są dostępne.

Pełniejszy mini język dla fragmentów makefile'i. Zamiast ustawiać magiczne zmienne dla make i mieć najdzieję, że Rules.make zrobi to czego oczekujesz, w plikach Makefile.in jest zawarte to co byś chciał zrobić, kbuild 2.5 troszczy się o spełnienie twoich wymagañ.

Tryb wyciszony. Domyślnie kbuild 2.5 wypisuje jedną linijkę dla każdej kompilacji, scalania lub komendy zdefiniowanej przez użytkownika. Wszystkie inne komunikaty - ostrzeżenia i błędy są teraz łatwiejsze do zauważenia. Oczywiście w dalszym ciągu możesz oglądać wszystkie komendy jeśli naprawdę jest Ci to potrzebne.

Standardowa obsługa rozpowszechniania wygenerowanych plików. kbuild 2.4 miał ciągłe problemy z plikami, które są zarówno generowane jak i rozpowszechniane. Dzieje się tak głównie, gdy proces generacji wymaga narzędzi, które nie każdy użytkownik ma zainstalowane w kbuild 2.5. Problem ten zyskał standardowe rozwiązanie, które powinno pozwolić uniknąc problemów z kbuild 2.4.

Poprawne działanie równoległe. Możesz wykonać make -j na wszystkich komendach i kbuild 2.5 zapewni, że będą one wykonywane we właściwej kolejności.

Przy jednym poleceniu make można określić wiele celów. Nie możesz mieszać clean albo mrproper z innymi celami, ale wszystko poza tym może być umieszczone w jednym poleceniu.
make -j oldconfig installable && sudo make -j install
pięknie działa.

Cele instalacyjne takie jak bzImage, zImage, miejsce do którego instalować System.map i .config, prefix ścieżki w której instalujemy, to, które komendy należy wykonać po install itp są opcjami CONFIG_. Skopiuj .config z jednego jądra do innego, uruchom make install i samo się dzieje, bez pomocy.

Użytkownicy, którzy wymagają dodatkowego przetwarzania mogą dynamicznie określić dodatkowe cele, w każdym momencie cyklu kompilacji. To może być użyteczne dla uruchomienia kodu specyficznego dla dystrybucji bez zmian w makefile'ach.

Możesz kompilować pojedyncze cele, na każdym poziomie w drzewie kodu, co jest użyteczne gdy zajmujesz się kodem. Możesz też skompilować wszystko w danym katalogu, z lub bez rekursywnego zejścia do podkatalogów. Inaczej niż w make SUBDIRS= z kbuild 2.4, kbuild 2.5 nie wyprodukuje niespójnych jąder.

Numer wersji jądra jest zwiększany tylko gdy vmlinux jest przebudowywany, nie przy każdym wykonaniu make.

Możesz zmienić nazwy katalogom ze źródłami i binariami i nie musisz potem niczego rekompilować.

To jest udokumentowane! Przeczytaj Documentation/kbuild/kbuild-2.5.txt.

TODO:

Dodanie nowych architektur. Wersja 1 obsługuje jedynie ix86. Następna będzie IA64, ponieważ mam do niej dostęp. Potem będzie to zależne od wsparcia od grup ludzi zajmujących się innymi architekturami.

Łata dla jąder -ac (być może). Trzeba jedynie prześledzić zmiany w Makefile'ach w -ac, główny kod kbuilda jest taki sam dla jąder -ac.

Pomoc przy konwersji zewnętrznych źródeł do formatu kbuilda 2.5. XFS jest już przekonwertowany, będzie się kompilował zarówno z kbuildem 2.4 jak i 2.5. http://marc.theaimsgroup.com/?l=linux-xfs&m=99701265316648&w=2

Poprawienie wydajności. Część kodu ma złożoność O(n**2) względem liczby obiektów, które są kompilowane. Dla małych kompilacji kbuild 2.5 jest około 10% szybszy niż wykonanie make dep i make bzImage w 2.4. Dla pełnych kompilacji jądra, kbuild 2.5 jest dwa razy wolniejszy niż kbuild 2.4. Wiem, w którym miejscu występują problemy i pracuję nad nimi. MEC mantra

Przede wszystkim poprawność.
Potem zarządzalność.
Na koniec szybkość działania.

Dodanie obsługi symboli wersji modułów. Stare genksyms było fajnym pomysłem, ale implementacja miała dość podstawowe problemy na poziomie projektu i zostało usunięta. Poprawną obsługę symboli wersji modułów dodam później, gdy już jądro 2.5 będzie istnieć. Poprawna implementacja wymaga ukazania się nowej wersji modutils.

Usunięcie niepotrzebnych już plików z paczki z jądrem.

Przekształcenie względnych włączeñ plików nagłówkowych (#include "../..") aby wyplenić założenie o strukturze drzewa jądra, które stwarza problemy, gdy kod jest przenoszony z miejsca na miejsce.

Uwe Starke zapytał, czy nowa wersja karty AVM FritzCard PCI jest obsługiwana w ostatnich wersjach jądra. Kilku gości odpowiedziało, że nie ma tej obsługi, ale Kai Germaschewski odpowiedział " Właśnie umieściłem pierwszy, rozwojowy, snapshot na http://www.tp1.ruhr-uni-bochum.de/~kai/i4l/hisax/."


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	30 Jul 2001 - 2 Aug 2001	(12 posts)	Stan prac nad sterownikiem Tulipa
2.	30 Jul 2001 - 2 Aug 2001	(18 posts)	Wsparcie dla wielu dysków SCSI
3.	1 Aug 2001 - 3 Aug 2001	(21 posts)	Stan SMP na systemach z procesorami AMD
4.	1 Aug 2001	(1 post)	Wsparcie dla /dev/bios
5.	2 Aug 2001 - 3 Aug 2001	(5 posts)	Identyfikowanie modułów wegług adresów
6.	7 Aug 2001 - 8 Aug 2001	(12 posts)	Nowa wersja Kernel Build Tools
7.	9 Aug 2001	(5 posts)	Stan obsługi AVM FritzCard PCI v2.0

Kernel Traffic #130 For 13 Aug 2001

By Zack Brown

Translated By: Maja Królikowska , Paweł Kot and Tomasz Torcz