Kernel Traffic #140 For 5 Nov 2001

Przywróciłem indeksowanie, ale nie umiem powiedzieć, jak długo ono pozostanie. Jeśli znowu będę miał problemy z bazą danych, być może będę musiał je znów wyłączyć.

Na początek można obejrzeć listę wszystkich ludzi, którzy pisali sprawozdania dla KT lub dla któregokolwiek z Cousinów, pod adresem http://kt.zork.net/authors.html. Niestety jeszcze nie dodałem tłumaczy. Może pewnego dnia...

Lista autorów to tylko dodatek. Naprawdę fajną rzeczą jest to, że możesz obejrzeć indeks ludzi z list dyskusyjnych, którzy byli cytowani, albo odwoływano się do nich w KT lub Cousinach. Główny indeks znajduje się pod adresem http://kt.zork.net/people.html. Tak naprawdę są dwie główne strony z indeksem. Jedna, którą właśnie wymieniłem, zawiera listę alfabetyczną, a inna, dostępna pod adresem: http://kt.zork.net/peoplebycontrib.html, podaje wszystkich w porządku liczby pojawieñ się w KT lub Cousinach.

Każda z tych głównych stron indeksowych zawiera odnośniki do OGROMNEJ liczby mniejszych indeksów dla każdej pojedynczej osoby. Mniejsze indeksy są także połączone z nazwiskami ludzi pojawiającymi się w kolejnych odcinkach. Takie odnośniki w KT i w Cousinach oznaczone są przez "[*]" i umieszczone bezpośrednio za nazwiskiem danej osoby.

Każda strona indeksowa pojedynczej osoby zawiera różnorodne informacje. Weźmy jako przykład Wicherta Akkermana. Podane są wszystkie jego pojawienia się odnotowane przez Cousin (lub KT) wraz z datą i tytułem dyskusji. Pod spodem znajdują się dwie kolumny (także uporządkowane według różnych Cousinów), zawierające nazwiska wszystkich ludzi, którzy byli zaangażowani w dyskusję z Wichertem, oraz liczbę takich wypadków. Lewa kolumna uporządkowana jest alfabetycznie, a prawa względem liczby podejmowanych dyskusji. Te kolumny są także ułożone według poszczególnych Cousinów. Pod każdym nazwiskiem jest także odnośnik do osobistej strony indeksowej tej osoby, zatem można swobodnie surfować pomiędzy stronami indeksowymi.

Bawcie się dobrze! I jeśli znajdziecie jakieś błędy, to chciałbym się o nich dowiedzieć.

There were 587 different contributors. 266 posted more than once. 159 posted last week too.

W trakcie dyskusji, Alexander Viro zaczął podsyłać uwagi na temat błędów w devfs na listę l-k. Po kilku odpowiedziach na własne wiadomości i kolejnych zgłoszeniach, Ryan Cumming zasugerował: "Być może bardziej użyteczne byłoby, gdybyś dołączał łaty, bądź przynajmniej podał konstruktywne pomysły, jak rozwiązać te problemy, ponieważ na pewno jesteś w stanie to zrobić. Przekopywanie się przez kod i wysyłanie nowych wiadomości na listę przy każdym nowym błędzie, który znajdziesz, nie jest dobrym pomysłem, a Twoje ataki osobiste na osobę zarządzającą tym kodem są już zupełnie bez sensu. Współpraca zaprowadzi Cię dalej niż wojna." Alexander odpowiedział:

Już to przerabialiśmy. Próbowałem tego, ale Richard powiedział, że woli te błędy poprawić sam. Kilka miesięcy temu. Jeśli masz lepsze propozycje, chętnie ich wysłucham.

Z tego, co widzę, opiekun nie poprawia błędów samodzielnie i mówi, że nie przyjmuje łat. Są jedynie dwa wyjścia z sytuacji: przejście w tryb całkowitej otwartości w nadziei, że zmieni to sytuację oraz przejęcie kodu, o którym mowa.

W tej chwili bardzo mnie kusi, aby wybrać tę druga możliwość (tzn. całkowite oddzielenie, zarządzanie bez oglądania się na Richarda + zgłaszanie [bardzo intensywne] poprawek bezpośrednio Linusowi), ale chciałbym najpierw spróbować postąpić mniej brutalnie.

tak, Al Viro jest w stanie wysłać poprawki do devfs i nawet tak zrobił jakiś czas temu (IIRC mniej więcej 2 miesiące temu)
wówczas Richard Gooch powiedział Alowi, że zaczął już pracę nad poprawką i wolałby zrobić to własnoręcznie ... i jak to tej pory nie widziałem, aby tak się stało

Richard Gooch odpowiedział na to, mówiąc, że Alexander wysłał "naprawdę koszmarną łatę z aktywnym oczekiwaniem, którą szybko zastąpiłem dużo ładniejszym odpowiednikiem. I, po jakimś czasie, moja łata została zaaplikowana przez Linusa." Jako komentarz do słów Rika i Alexandra odnośnie przeszłych dyskusji, dodał:

Wierutne, pieprzone bzdury. Przez ostatnich parę miesięcy regularnie wysyłałem łaty z poprawkami błędów do Linusa i na listę, i jeśli byście zwrócili uwagę, zauważylibyście je w momencie, gdy zostały zaaplikowane.

Co więcej, prawie skoñczyłem przepisywanie większej części devfs, która dodaje prawidłowe blokowanie i zliczanie referencji. Prace sukcesywnie posuwały się naprzód (a jest przy tym dużo roboty), ale niestety tymczasowo zostały przerwane z powodu ważnej podróży. Prace powinny się zakoñczyć w ciągu kilku tygodni. Nie ma sensu, abym wysyłał niedokoñczoną wersję kodu.

Nie mam pojęcia, czemu twierdzicie, że nie dokonałem żadnych zmian, podczas gdy wysyłałem ogłoszenia o nowych łatach na listę, a nawet można znaleźć notatki na ich temat w ChangeLogach Linusa. Jeśli nie wiecie, co się dzieje, dlaczego od razu się na ten temat wypowiadacie? Co byście powiedzieli, gdybym zaczął narzekać na to, ile czasu zajęła praca nad VM tak, aby zaczął działać? Nasz VM obsysał od *lat*.

Tia, _teraz_ naprawdę się wkurzyłem. Z tego co widzę, jest tylko jeden sposób abyś coś poprawił -- wysyłanie na l-k. Czymże są te ,,regularne aktualizacje''? Popatrzmy:

0.118: niedopełnienie bufora w try_modload(). Źródło: niejaki Al Viro znalazł rzeczoną funkcję, grepując całe drzewo i spędził kilka minut na jej czytaniu.

0.118: przeniesienie down_read() - tak, to usunęło blokadę, wskazaną Ci przez, kurde, co za zbieg okoliczności, tego samego drania. Pomyślmy chwilę, przegrepuję pod kątem down_read()... Aha.

static int devfs_follow_link (struct dentry *dentry, struct nameidata *nd)
{

int err;
struct devfs_entry *de;

de = get_devfs_entry_from_vfs_inode (dentry->d_inode, TRUE);
if (!de) return -ENODEV;
down_read (&symlink_rwsem);
err = de->registered ? vfs_follow_link (nd, de->u.symlink.linkname) : -ENODEV;
up_read (&symlink_rwsem);
return err;

} /* Koniec funkcji devfs_follow_link */

Umm... Czy już tu nie byliśmy? Rekursyjne down_read(&symlink_rwsem)...

0.117: łeeeee -- nareszcie. devfs_link() znikło.

0.116: odwrócona poprzednia, nieprawidłowa łata, ale zaowocowało to w blokadzie zamiast wyścigu. Wynik wyścigu opisany na l-k przez... kurna, znowu ten dupek.

0.115: bezsensowna poprawka błędu wprowadzonego przez łatę blkdev-in-pagecache. Ale nie dostała się do drzewa Linusa.

0.114: wprowadzone niedziałające zliczanie referencji dla symbolicznych dowiązañ (patrz 0.116)

0.113: ,,szybki i brzydki trik'' do ochrony ciał symboliczych dowiązañ. W dodatku nieprawidłowy. BTW, błędy w 0.113 i 0.114 nie powstrzymały Mandrake przed twierdzeniem, że naprawiło wyścig w readlink() i włączeniem tego czegoś do dystrybucji. Śmieszne, bo wyścig został w zasadzie naprawiony w prywatnej korespondencji kilka miesięcy wcześniej. Później był opisywany na l-k. Następnie opis został przekazany do Mandrake -- po pytaniach o potencjalne błędy. _Wówczas_ (zakładam, że przez przypadek) pojawiły się wspomniane łaty.

0.111, 0.112: nijak nie umiem się doszukać poprawek.

A, i ciut wcześniej (w koñcu, po ledwie roku nadmieniania o tym dziadostwie, ciężkiej kłótni na l-k, gdy w koñcu straciłem cierpliwość _i_ szegółowej dyskusji na temat możliwych poprawek) poprawka wyścigów expand-entry-table.

Zatem, jak widzę, najlepszym sposobem, abyś naprawił przynajmniej błędy wyraźnie Ci wskazane, jest publiczne łajanie Cię. Dokładnie tak. Wyraźnie widzę, że nie czytasz własnego kodu. Widzę to przy każdym ponownym zaglądnięciu do fs/devfs/base.c, gdy, po paru minutach, znajduję kolejną dziurę, która tam pozostaje do momentu ogłoszenia jej na l-k. Prywatne maile nie odnoszą skutku. Czytasz, odpowiadasz i ignorujesz. Mam dostępnych około stu kilobajtów dowodów.

Nie widzisz tych raportów z błędami, czy też pytañ, na które odpowiadam, a które są wysyłane do mnie prywatnie, czy też na listę devfs (wiem, że nie jesteś zapisany :-). No i chyba zapomniałeś, że odpowiedziałem na pytania i raporty z błedami *od Ciebie*, które przysłałeś mi prywatnie, czasem z Cc: do Linusa. Odpowiedziałem nawet na pytania, które umieściłeś w kodzie. Zatem nieprawdą jest, iż odpowiadam jedynie wywołany do tablicy. Postęp *dokonuje* się, niezależnie od tego, co insynuujesz.

Co do ostatnich zgłoszeñ błędów, tak, widziałem je. Odpowiem na nie (nie dlatego, że tak na to nalegasz na liście) jeszcze w tym tygodniu, po tym, jak przekopię się przez swoją pocztę, która nagromadziła się podczas mojej tygodniowej nieobecności w necie. Tia, to zabiera trochę czasu, aby przebrnąć przez całą skrzynkę, zwłaszcza, gdy dostaję dużą porcję wyzewnętrznieñ.

Odnośnie pracy, którą Richard wykonywał ostatnio, Roman Zippel spytał: "A może by tak umieścić te źródła w jakimś repozytorium CVS, tak aby ludzie mogli zobaczyć, co się dzieje i być może nawet pomóc? BTW, powinieneś coś zrobić ze swoim stylem kodowania, gdyż Twój kod jest nieczytelny. Nie dbałbym o to, gdyby to był jakiś sterownik, ale devfs ma być bardzo ważną częścią jądra, więc byłoby miło kodować wedle tych samych zasad, co inne ważne części jądra." Alexander odpowiedział: "Wygląda na to, że w ciągu kilku dni stworzę repozytorium CVS, bazujące na ostatnim opublikowanym kodzie..."

George Anzinger miał zamiar stworzyć POSIX-owy zegar, który nie przekręcałby się na 0 w żadnym momencie. Wymyślił, że najlepszym sposobem na implementację będzie użycie mechanizmu podobnego do uptime, który używał wartości jiffie. Ale ponieważ jiffie mogą się przekręcić do 0, wymyślił, że musi to obejść w jakiś sposób. Zrobienie z jiffie wartości 64-bitowej zamiast 32-bitowej znacznie polepszyłoby sytuację. Przedstawił kilka propozycji, z których każda miała wady, które wymienił. Keith Owens zaproponował:

Jeśli chcesz pozostawić istniejące jądra bez zmian, tak aby dalej używało 32-bitowych jiffie, użyj po prostu oddzielnego 32-bitowego pola, które będzie używane jedynie przez kod, który tego potrzebuje. Na 32-bitowych maszynach, kod jiffie wygląda tak:

old_jiffies = jiffies++; if (jiffies < old_jiffies)

++high_jiffies;

Będziesz potrzebował blokady wokół tego na 32-bitowych maszynach, ale tak się robi zawsze, gdy operuje się na 64-bitowych licznikach na 32-bitowych maszynach. Żadna z Twoich sugestii nie zadziała na ix86, która to architektura nie pozwala na sprzętową niepodzielną aktualizację 64-bitowych pól.

Brian Gerst zauważył, że cmpxchg8b obsługiwało niepodzielne sprzętowe aktualizacje 64-bitowych pól, ale Keith odpowiedział: "Nie na 386, ale na 486 i nowszych. Poza tym, chcesz uniknąć specyficznego dla architektury kodu asemblerowego."

George odpowiedział na uwagi Keitha mówiąc: "Jak się okazuje, już mam zrobioną blokadę wokół kodu aktualizującego jiffie. Przyczyną, dla której można chcieć używać 64-bitowych integerów jest to, że kompilator ZDECYDOWANIE lepiej radzi sobie z ++, tzn. po prostu wykonuje proste dodanie. Żadnych ifów, żadnych jmp. Sądzę, że będę musiał również blokować odczyt, ale nie jest on wykonywany zbyt często i w zasadzie nie będzie za bardzo blokował."

Dodał, że coś w rodzaju ,,

#define jiffies (unsigned long
volitial)jiffies_u64

'' wyglądało na razie na najlepszy pomysł (czyli proste rzutowanie jiffie na odpowiedni rozmiar). Ale Linus Torvalds zaoponował:

poza gcc, które zachowuje się źle nawet w przypadku konwersji 64->32 bity. Zazwyczaj załaduje pełną 64-bitową wartość, a później będzie używać jedynie młodszych bitów.

Wydajnym i rozsądnym sposobem na robienie czegoś takiego jest:

/* * 64-bitowa wartość nie jest typu volatile - nie WOLNO jej * odczytać bez założenia blokady */ u64 jiffies_64; /* * Większości ludzi nie zależy na pełnej wartości 64-bitowej, * więc możemy pobrać ,,niestabilne'' młodsze bity bez zakładania * blokady. Z historycznych powodów oznaczamy ją jako volatile, * aby aktywne oczekiwanie nie zostało zoptymalizowane w starych * sterownikach. */ #if defined(__LITTLE_ENDIAN) || (BITS_PER_LONG > 32) #define jiffies (((volatile unsigned long *)&jiffies_64)[0]) #else #define jiffies (((volatile unsigned long *)&jiffies_64)[1]) #endif

... co wygląda paskudnie, ale ta brzydota jest ograniczona jedynie do tego miejsca i żaden z użytkowników nie będzie musiał się tym przejmować.

George miał przeczucie, że można ro poprawić unikając blokowania. Wysłał wersję, która miała tak właśnie działać na systemach jednoprocesorowych, ale nie był pewien czy istnieje odpowadająca jej wersja dla systemów wieloprocesorowych. Nie było odpowiedzi.

3. Dalsza dyskusja na temat wyboru obsługi pamięci wirtualnej w trakcie kompilacji

Marton Kadar zapytał, czy byłoby możliwym udostępnienie wyboru podsystemu pamięci wirtualnej, jako opcji kompilacji. Reidowi Hekmanowi wydawało się, że temat ten został już przewałkowany, ale Lars Marowsky-Bree dodał w odpowiedzi, "być może będzie na to miejsce w 2.5, ale wydaje mi się, że podsystem powinien być zmodularyzowany; sądzę, że dowiedziono, iż ta część kodu jest niewątpliwie tematem dyskusji i zaryzykowałbym stwierdzenie, że być może optymalna obsługa pamięci wirtualnej, służąca różnym podejściom, nie istnieje, i możliwość przełączania opcji VM w trakcie działania systemu byłaby użyteczna. " Rik van Riel skomentował:

Ciekawe, że spośród wszystkich ludzi mówiących, ze powinniśmy mieć różne systemy pamięci wirtualnej w różnych stuacjach, NIKOMU nie udało się wskazać, jakie konkretnie rzeczy powinny być różne.

Obecna sytuacja, w której mamy 2 konkurencyjne systemy pamięci wirtualnej, wydaje się jednak nieźle działać. Szczególnie, kiedy cały czas wykorzystywane są na raz różne pomysły.

Madhav Diwan zapytał, który kompilator jest najlepszy do kompilacji jądra; używał on gcc-2.96-85 z Red Hata, ale był ostrzegany, że to może coś popsuć. Sam nie zauważył takiego zachowania, ale był ciekaw, czy jest lepszy wybór. David Weinehall odparł: "niektórzy ludzie ciągle trwają w błędnym przekonaniu, że wszytskie wersje gcc-2.96 są pełne błędów. Nie są; tak jest tylko z wczesnymi wersjami. gcc-2.95.[34] oraz gcc-2.96-(nowsze wersje) są dobrymi wyborami, jeśli chcesz mieć działające jądro. Niektóre inne wersje też mają szansę działać, ale powtórzę, że mogą nie działać :-)" Alan Cox dodał, że aktualnie używa gcc-2.96-85 (dokładnie takiego, jakiego używał Madhav). Zaznaczył również, że "Gcc 3.0 nie zawsze buduje poprawne jądra. To głównie dlatego, że jest to wersja .0 - nowa infrastruktura, pewien rdzeñ, który potrafi robić znacznie lepsze rzeczy niż gcc 2.*, ale jeszcze nie daje takich rezultatów, trzeba poczekać aż wszystkie błędy zostaną wywalone."

Alan Cox ogłosił 2.4.13-ac1, w którym, jak powiedział, zawarł scalenie ze źródłami utrzymywanymi przez Linusa Torvaldsa. Christopher S. Swingley zapytał: "Czy to znaczy, że seria ac używa teraz VM AA, czy to scalenie dotyczy wszystkiego innego niż VM, jak to było we wcześniejszych 2.4.1x-ac? " Alan odpowiedział, że ciągle używa podsystemu pamięci wirtualnej Rika van Riela, ale "sprawy układają się tak, że podejrzewam, iż 2.4.14ac* będzie dobrym momentem na przejście na VM Andrei/Marcelo/Linusa."

Keith Owens wysłał listę licencji, które będą piętnowały jądro, wyjaśniając, ",,BSD bez klauzuli o ogłaszaniu'' nie jest wystarczająco dobra dla jądra, ta licencja dopuszcza moduły dostępne jedynie w formie binariów. Ci, którzy szukają błędów w jądrze, naciskają na ogólną dostępność źródeł. Ponieważ część źródeł, która jest już w jądrze, jest dystrybuowana na GPL, to źródła te mają w sumie podwójną licencję - BSD/GPL. Czy właściciele licencji mogli by je zmienić na ,,Podwójna BSD/GPL''?" Andreas Dilger odpowiedział: "Włączenie w kod źródła nie oznacza "ogólnej dostępności źródeł"? Widzę, że chcesz, by cały ten bałagan z piętnowanymi jądrami zaczał działać, ale sądzę, iż mylisz intencje z implementacją. Intecją (AFAICS) było piętnowanie jądra TYLKO wtedy, gdy załadowany jest moduł o zamkniętym kodzie, a nie mechanizm prowadzenia ,,polityki licencji'', szczególnie w przypadku źródeł, które dawno temu zostały włączone do jądra. " Alan Cox odrzekł:

,,BSD'' może stosować się do kompletnie zamkniętego materiału, jak też do innych rzeczy

Keith ma też rację - jeśli kod na BSD jest zgodny z GPL i włączony do jądra, to poprawnym jest również opisanie go licencją podwójną - BSD/GPL.

Roy Sigurd Karlsbakk spytał, czy są obsługiwane chipy Sigma 8400/8401. Anton Altaparmakov odpowiedział:

http://www.sigmadesigns.com/support/download_netstream2000_linux.htm

zawiera oficjalne sterowniki dla karty Netstream2000, która używa układu em8400, lecz są one dostępne jedynie w postaci binarnej.

Jeśli używasz tego chipa w celu utworzenia własnej platformy, powinieneś skontaktować się z projektem sigma dla sterowników linuksowych. Adres, pod którym można przeczytać, że jest obsługa tego układu to:

http://www.sigmadesigns.com/products/em8400.htm

Jako że Sigma nie udostępnia specyfikacji ani kodu źródłowego, nie ma żadnego sterownika z otwartym kodem i nie wiem o żadnych nieformalnych projektach, mających na celu napisane takich sterowników.

Jeśli chodzi Ci o chip em8300 to zajrzyj pod http://dxr3.sf.net/, gdzie możesz znaleźć nieoficjalne sterowniki Linuksowe, na GPL, dla Sigma Realmagic Hollywood+ i kart Creative dxr3 (bo to to samo).

Roy Sigurd Karlsbakk odpowiedział, " dziwne... Na stronach Sigma znalazłem paczkę z tymi sterownikami, nazwaną NetStream2000-0.2.047.1.tar.gz, zawierającą źródła. Również na ich stonach znalazłem specyfikację techniczną EM840[01], jednakże dokument ten był oznaczony jako 'poufny'. " Ale Torrey Hoffman wyjaśnił:

Kod źródłowy na GPL (z katalogu ,,kernelmode'' w paczce) zawiera jedynie źródła interfejsu pomiędzy sterownikiem a jądrem. Ich kompilacja da Ci mały moduł, ale AFAIK, nie ma sposobu (no cóż, nie ma dokumentacji) na użycie tego modułu w celu zrobienia czegoś użytecznego lub interesującego.

Żeby faktycznie cokolwiek zrobić (na przykład zdekodować MPEG-2) przy użyciu tego sprzętu, musisz użyć dużej (400K) biblioteki libEM8400.so, biblioteki, której kod jest zamknięty. Ta biblioteka komunikuje się ze sprzętem przy użyciu modułu. Podejrzewam, że możesz spróbować to odcyfrować (reverse engineer) obserwując komunikację między biblioteką a sterownikiem, ale to najprawdopodobniej jest niedozwolone.

Zatem, w skrócie: Jedyna dokumentacja dotyczy tego jak używać libEM8400, czyli czegoś z kodem zamkniętym. Hej, to jednak działa, więc mogłoby być gorzej.

(Podejrzewam, że można dyskutować na temat legalności tego modułu jądra, który jest na GPL / sterownika z zamkniętym kodem, ale jestem pewien, że większość czytelników listy ma dość amatorskich dyskusji prawniczych, podejrzewam, iż prawnicy Sigmy zdecydowali, że jest to legalne i oni wiedzą to lepiej ode mnie.)


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

1.	17 Oct 2001 - 28 Oct 2001	(54 posts)	Al Viro planuje podział devfs
2.	22 Oct 2001 - 26 Oct 2001	(7 posts)	W poszukiwaniu monotonicznego zegara
3.	25 Oct 2001	(10 posts)	Dalsza dyskusja na temat wyboru obsługi pamięci wirtualnej w trakcie kompilacji
4.	25 Oct 2001 - 26 Oct 2001	(15 posts)	Którego kompilatora użyć
5.	26 Oct 2001	(8 posts)	Alan skłania się ku VM Andrei
6.	26 Oct 2001 - 29 Oct 2001	(8 posts)	Dalsza dyskusja na temat piętnowania licencjami
7.	31 Oct 2001	(5 posts)	Obsługa układu Sigma 8400/8401 jedynie w formie binarnej

Kernel Traffic #140 For 5 Nov 2001

By Zack Brown

Translated By: Maja Królikowska and Paweł Kot