Kernel Traffic #149 For 7 Jan 2002

Po prostu nie sądzę, aby było to interesujące. Algorytm szeregowania zajmuje około 100 linii z iluś-tam-milionów (3.8 przy ostatnim liczeniu) i nie ma zbyt dużego wpływu na normalne działanie.

Kiedyś na pewno zrobimy kolejki per procesor, czy coś takiego. Ale to mnie martwi dużo mniej niż takie rzeczy, jak VM, czy warstwa urządzeñ blokowych ;)

Wiem, że wiele osób uważa algorytm szeregujący za istotny, a teoria systemów operacyjnych bardzo się na ich temat rozwodzi -- to jest jedna z rzeczy, o które ludzie mogą się zawsze kłócić oraz jest wystarczająco prosta koncepcyjnie, aby ludzie się jej nie bali. Osobiście nigdy nie sądziłem, aby było to szczególnie istotne zagadnienie.

Spójrzmy prawdzie w oczy -- obecny scheduler ma dokładnie tę samą prostą strukturę, którą miał już prawie 10 lat temu, i tak, nie jest ona optymalna, ale tak naprawdę obciążenia, przy których przeszkadzałoby to ludziom, w rzeczywistym świecie się nie zdarzają. Przykro mi, ale to prawda.

I musisz zrozumieć, że nie tak wiele kawałków kodu dożyło takiego wieku jak scheduler. Co jest jeszcze jednym dowodem na to, że szeregowanie jest proste.

W ciągu ostatnich 10 lat już kilka razy przepisaliśmy VM i przypuszczam, że tak się stanie jeszcze kilka razy w ciągu najbliższych paru lat. Przez ostatnie pięć lat dowiedzieliśmy się, że w obecnych trzywarstwowych tablicach stron powinny być cztery warstwy itd.

Podejrzewam, że w porównaniu do takich problemów, stworzenie kolejek per procesor i logiki do rozkładania obciążenia pomiędzy procesorami w algorytmie szeregującym jest _trywialne_. Łaty istnieją i nie sądzę, aby ludzie mogli za bardzo spieprzyć te kilkaset linii kodu.

Zrób to sam. Nie angażuj mnie, ponieważ nie sądzę, aby to było jakiekolwiek wyzwanie. W 1991 napisałem kawałek kodu, który _cały czas_ stanowi większość algorytmu i to jest, kurczę, w zasadzie jedyny kawałek kodu, który został w miarę nietknięty do tej pory. Całe ,,ponowne obliczanie priorytetów, gdy wszystkie spadły do zera'' było tam od samego początku.

To powoduje, że mówię: ,,oh, szybki hack z 1991 działa na większości komputerów w 2001, więc jak trudny może być ten problem?''

Zrób to sam. Ludzie pytali, czy jestem zainteresowany, a ja mówiłem ,,nie''. Zrób tak: przeprowadź testy porównawcze na wszystkich konkurujących łatach i spróbuj stworzyć najlepszy. Wtedy zgłoś się do mnie z gotowym rozwiązaniem.

No cóż, jeśli ludzie nie są zainteresowani, to w to na pewno _nigdy_ nie wejdą.

Zapamiętaj: nie dodajemy nowych rzeczy, tylko dlatego, że możemy.

Tak szczerze, nie uważam, że powiedziałeś tak do wielu ludzi. Nie zauważyłem żadnej dyskusji na linux-kernel o aio, być może dlatego, że wysłałeś kilka ogłoszeñ i nikt nie zwócił uwagi, albo wspomniałeś tylko przelotnie i ludzie nie zauważyli.

Spójrz jak długo zajęło, zanim ext3 został ,,standardem'' - włączyłem to do mojego drzewa, kiedy zacząłem dostawać prawdziwe sygnały, że jest używane i ludzie lubią tego używać. Po prostu nie lubię dodawać łatek ,,żeby zdobyć użytkowników''. Nawet rezerwacji - bo rezerwuję sobie prawo, aby _nigdy_ nie włączać czegoś, jeśli ocena krytyczna brzmi ,,to nie ma sensu''.

Tak szczerze, fakt testowania tego przez ludzi z miejsc takich jak Oracle etc. jest drugorzędny - ci ludzie będą używać czegokolwiek. Dowiodła tego historia. Nie oznacza to, że _ja_ zaakceptuję cokolwiek.

Fakt, że lubię interfejsy jest w zasadzie drugorzędny - sprawia to, że jestem bardziej chętny, aby to włączyć nawet do na wpół gotowej rzeczy, ale NIE oznacza, że ufam mojemu gustowi wystarczająco, aby włączyć to ,,pod przykryciem'' ze szczątkową otwartą dyskusją, użytkowaniem i zmianami.

Gdzie _jest_ dyskusja na linux-kernel?

Gdzie są wszystkie negatywne komentarze od Ala? (Al _zawsze_ ma negatywne komentarze i sugestie poprawek, nie próbujcie mówić, że jemu to się też podoba bez żadnych zastrzeżeñ ;)

Ech.

Obok _wielkiego_ problemu z otwieraniem asynchronicznego API dla przestrzeni użytkownika (z wielu powodów, włączając zwyczajową jakość kodu asynchronicznego w ogólności i w szczególności jeden sterownik sterowany zdarzeniami), jest jeszcze bardziej szczególny - długo oczekiwane, w pełni synchroniczne writepage() z przyjaciółmi od Bena. Uwierzę jak zobaczę, a na razie nie pojawiło się.

Zatem, na jakiś czas się, kurna, z tego usuwam -- nie podoba mi się to, ale jestem już zmęczony tym rodzajem wojen religijnych.

Dziękuję bardzo, nie jestem zapisany na żadną. Czytuję je przez bramkę newsową, która daje mi dostęp do tych ważniejszych.

A jeśli dyskusja nie odbyła się na żadnej z nich, to nie była to otwarta dyskusja.

I nie, przykro mi, ale IRC również się nie liczy.

większość przydatnego ruchu na lkml nie da się wyrazić na IRC-u. Jakkolwiek IRC może być przydatny jako wspomagająca forma kanału komunikacyjnego, MSZ listy email winny pozostać główną siłą kierunkującą rozwój jądra Linuksa, inaczej skoncentrujemy się tylko na tych drobnych pomysłach, które dadzą się wyrazić w 1-2 linijkach na irc-u i które są wystarczająco proste, aby można było je zrozumieć, dopóki nie pojawi się następna wiadomość. Także brak niezawodnej archiwizacji IRC-a uniemożliwia nowym osobom późniejsze odtworzenie przebiegu myślowego. O ile IRC może spowodować szybkie napisanie superłatki przez doświadczonego opiekuna jądra, ostatecznie jednak będzie izolował i alienował nowicjuszy i doprowadzi do powstania starzejącej się, nacechowanej osobowo elitarnej sieci starszych panów i umierającego OS.

Rozważając używanie IRC-a jako głównego medium rozwoju jądra Linuksa - szybkie tempo IRC-a często powstrzymuje głębsze przemyślenia - o ile jest to z pewnością dla wielu ludzi powód, aby IRC-a używać, o tyle nie może zaowocować lepszym jądrem. [powiedziawszy powyższe muszę zaznaczyć, że używam IRC-a na codzieñ, nie było to więc rzucanie kalumni na irc-a, rzadko jednak używam go do rozwoju oprogramowania.]

Prawdą jest, że czytanie listów nie na temat na lkml, także nie jest mądrym wykorzystywaniem mocy rozwojowej, ale trzeba to wkalkulować, tak samo jak spam - to cena za posiadanie otwartego forum.

i szczerze mówiąc, większość narzekañ na jakość lkml jest przesadzona. To, czego nie bierzecie pod uwagę to fakt, że o ile 3 lub 5 lat temu prawdopodobnie większość listów na lkml uważaliście za ekscytujące i dopingujące, o tyle dzisiaj jesteście dośwaidczonymi hakerami jądra i prawdopodobnie nudzi was 90% ruchu. Właśnie przeprowadziłem test - i być może wybrałem zły zestaw listów - ale większość ruchu na lkml jest właściwa i sam uznałbym je za "interesujące i ekscytujące" jeszcze 5 lat temu. Dziś wiem, co znaczą i zrozumienie ich może nie być już takim wyzwaniem - ale to jest jeden ze złych efektów ubocznych doświadczenia. Dziś na lkml jest więcej ludzi, zgłasza się więcej błędów i rozmawia się o większej liczbie łatek - bycie na bieżąco jest trudniejsze. Może miałoby sens rozdzielenie listy linux-kernel na dwie: linux-kernel-bugs i linux-kernel-devel (niemoderowane), lecz aktualny kształt i jakość dyskusji (kawa na ławę) jest, jak myślę, w porządku.

również bardziej oficjalne listy pasują do kształtu kodu źródłowego, niż nieoficjalny ruch na IRC-u. Dlatego też, kiedy się jest zmuszonym do ukształtowania wiadomości w większy fragment tekstu ASCII, będzie to pierwszy krok do dobrego kodu jądra.

(na IRC-u można być superhakerem z dobrze znanym pseudonimem, wchodzić i wychodzić z kanałów, być zagadywanym przez nowicjuszy. To może podbudować ego. Ale nie powinno utrudniać oceny.)

Przyglądam się tej Liście i mam parę pytañ, i byłbym wdzięczny za odpowiedż. Niektóre pewnie nie mają ostatecznych odpowiedzi i głosy na te tematy mogą być podzielone.

1. Czy jesteśmy zadowoleni z systemu kontroli kodu?
2. Czy dostatecznie wiele planów zostało poczynionych odnośnie dokumentacji? W jednym z listów znalazła się informacja, że jest nowe API, a my o nim nic nie wiemy.
3. Nie ma żadnej scentralizowanej bazy danych błędów. Ludzie powinni wiedzieć conajmniej o stanie błędów które znajdują w niektórych wersjach.
4. Agresywna natura tej listy może sama w sobie zniechęcić wiele osób, które chciałyby się przyłączyć.

Z poziomem 3 SEI CMM dla jądra, pełne testy i dokumentacja pozwoliłyby wypuszczać nowe jądra co pięć miesięcy, z nowymi sterownikami -- jakieś 2 lata po wypuszczeniu urządzeñ, a obsługa nowych platform pojawiałaby się po 2-3 latach po ich udostępnieniu. W chwili obecnej, nowe platformy jesteśmy w stanie obsługiwać 1-2 lata przed ich wejściem na rynek (na przykład tak, jak przy IA-64...)

W ten sposób usunęlibyśmy wszystkie korzyści, które przynosi bazarowy styl rozwijania kodu, podczas gdy nie zarobilibyśmy niczego specjalnego, oprócz wolnej maszynerii papierkowej roboty. Nie, dzięki.

Nie narzekam, gdy ludzie robią dobrą dokumentację i testy swojej pracy; raczej odwrotnie, ale to musi być robione ochotniczo, a nie wymuszane przez jakieś standardy. Czy naprawdę myślisz, że Linus mógłby wykonywać tę całą dodatkową robotę związaną z inżynierią oprogramowania? Pomyśl jeszcze raz. Czy szczerze wierzysz, że zaakceptuje to choćby za milion lat? Słaba nadzieja.

Wielka inżynieria oprogramowania oparta o PSP/CMM/cokolwiek jest w porządku, gdy masz jasny cel w głowie; plan określający, co jest do zrobienia, opisujący szczegóły. Nie dla czegoś, co zmienia kierunek rozwoju ot dla kaprysu, z tygodnia na tydzieñ, a jedynym tego celem jest poprawa sytuacji, rozwój i (czasem) uproszczenie.

Wydaje się, że to jest pomysł, tylko że do dziś nie widziałem jeszcze żadnego odpowiedniego rozwiązania dla tego.

Największym obecnie problemem jest to, że łatki są gubione, a bezpośrednią przyczyną takiego stanu jest to, że opiekunowie jąder nie dysponują nieskoñczonym czasem.

System, który miałby rozwiązać ten problem powinien ułatwiać opiekunom jąder zapamiętywanie jakie łaty mają, a tym samym oszczędzać ich czas. Wydaje mi się, że takie coś powinno składać się z następujących elementów:

1. zapamiętywanie łatek i ich opisów
2. dawać innym ludziom (opiekunom podsystemów) możliwość usuwania lub aktualizacji oczekujących łat
3. sprawdzać przy każdej wersji -pre czy łatki nie konfliktują, zgłaszać przesyłającemu sytuację, w której łatka już nie ma zastosowania
4. dać opiekunom łatwe, wymagające jednego kliknięcia rozwiązanie umożliwiające nałożenie łatki i dodanie linijki do changeloga ;) (wszystkie łatki, których nie da się nałożyć, zostają odesłane do opiekuna przez nr 3)
5. po każdej wersji -pre wysyłać opiekunowi jądra krótką relację na temat oczekujących łatek
6. łatkom możnaby przypisać priorytety tak, by opiekunowie jądra wiedzieli, nad którymi z nich spędzać więcej czasu
7. .. ?

Podsumowując, jeśli taki system kiedykolwiek zaistnieje, powinien _zmniejszać_ ilość pracy jaką mają opiekunowie, w przeciwnym razie nigdy nie będzie używany.

Mówiąc jako osoba, która _używa_ systemu śledzenia łat, wierzę, że system zarządzania łatami jest istotnym bólem.

Jeśli jakość łat nie jest dobra, to stawia Cię to w problematycznej sytuacji. Musisz dostarczyć ludziom powód odrzucania ich łatek, a to daje ludziom świetną możliwość dręczenia Cię jak to zrobić lepiej. Jeśli dostaniesz sporo takich łatek to w koñcu twoja skrzynka mailowa będzie zapełniona listami ludzi, którzy będą chcieli wiedzieć jak poprawiać te ich łatki.

Zazdroszczę Alanowi, Linusowi i Marcelo tego, że mają możliwość odrzucania łatek po cichu i czekania na ponowne ich przysyłanie. Osobiście nie wierzę, że system śledzenia łat ulatwia życie. Oczywiście używanie go oznacza, że nie możesz zgubić łatek, ale też to, że nie możesz ich specjalnie przypadkiem zgubić. To, imho, czyni życie znacznie trudniejszym.

Rik, to właśnie tłumaczy dlaczego nie uważam Cię za opiekuna jądra i nie będę się zajmował łatami od Ciebie. Nie jest warte mojego czasu przejmowanie się ludźmi, którzy nie mają zamiaru zajmować się, ani utrzymywać swoich łat.

Gdy Al Viro podsyła mi łatkę, którą nakładam i później podsyła mi do niej poprawkę, którą ominąłem z jakiegoś tam powodu, to daje mi to pewien komfort, wiem, że on _będzie_ jej pilnował, nie tylko kaprysił. To sprawia, że skłaniam się ku aplikowaniu jego łat w pierwszej kolejności.

Możesz zastąpić imię i nazwisko "Al Viro" nazwiskami Jeff Garzik, David Miller, Alan Cox, itd, itd. Rozumiesz o co mi chodzi?

To nie ma nic wspólnego z technologią. To dotyczy możliwości stałego rozwoju. Najważniejszą jego częścią jest to, że sami deweloperzy - odmawiam wpędzenia się samemu w sytuację, gdy to _ja_ muszę decydować kto jest lepszy - ludzi nie da się tak uszeregować. Zatem wymagam od innych więcej pracy. Myślcie o rozproszonym rozwijaniu.

Zauważcie, że rzeczy takie jak CVS nie pomagają w rozwiązaniu podstawowego problemu. Pozwalają na automatyczne akceptowanie łat i _zachęcają_ ludzi do zrzucania łat na innych i nie pomagają zachowywać się im, jak prawdziwym opiekunom.

Widzieliśmy to parę razy w Linuksie - na przykład David zwykł był utrzymywać wersję w CVS i skoñczył tę działalność sfrustrowany, bo musiał ją utrzymywać sam i porządkować niektóre złe części, tylko dlatego, że ja nie chciałem ich stosować (i on tego ode mnie nie chciał) i nie mógł zmusić ludzi do sprzątania, bo twierdzili, że ,,jak raz było włączone, to było włączone''.

Wiem, że zwolennicy kontroli źródeł powiedzą, że jej używanie pozwala ułatwić proces odrzucania złego kodu, ale to NIEPRAWDA. _Nie_ jest łatwiej odrzucać złe kawałki. Jedynym sposobem radzenia sobie z tym, co złe, jest nałożenie _odpowiedzialności_ na ludzi za ich własne g*wno i zmuszenie ich do opieki nad nim.

Ty odmawiasz takiego zachowania, a potem skarżysz się, gdy inni nie chcą opiekować się za ciebie twoim własnym kodem.

Jasne. Automatyczne wielokrotne podsyłanie łat można uznać za część pracy opiekuna, jeśli tylko testowanie ich zachowania jest także zautomatyzowane (znaczy jest dodawana automatycznie notka mówiąca, że łata została zweryfikowana).

To jest tak, że naprawdę _są_ ludzie, którzy wstawiają ,,mail torvalds < crap'' do crona. Bardzo szybko zostają częścią mojego filtru antyspamowego i dlatego nigdy _nic_ co stworzyli, nie dostało się do jądra, niezależnie od tego, czy proces był zautomatyzowany, czy nie..

oto pomysł:

Opiekunowie zajmujący się poszczególnymi fragmentami jądra, czy mający sprecyzowane zainteresowania, czy cokolwiek, mogą używać zamkniętego zbioru skryptów na serwerze webowym, który będzie działał jako kontroler robota nakładającego łaty, oraz mają dostępny zbiór maszyn, na których mogą wykonywać kompilacje.

(to znaczy davej, andrea, riel, itd. mieliby swoje własne serwery webowe, które zachowywałyby się jako centralne miejsca do składowania danych, jak też i miejsca, z których użytkownicy mogliby ściągać to, co chcą)

Tak naprawdę, kompilacja odbywa się na maszynach użytkowników, którzy chcą używać jądra, albo w przypadku dystrybucji, na wewnętrznych farmach utrzymywanych w tym celu. Użytkownicy mogliby mieć inny zestaw skryptów, które ściągałyby jądro, łatały je i budowały przy użyciu pliku konfiguracyjnego dostarczanego przez użytkowanika albo serwer. Skrypt przesyłałby wynik takiego budowania na serwer, tak by opiekunowie mogli widzieć co się zdarzyło, a serwer dostarczałby użytkownikom jakichś mechanizmów, które mówiłyby co działa, a co nie.

Jak tylko serwer webowy dostanie dane z powrotem, robot łatający może zdecydować, czy zastosowanie łaty skoñczyło się sukcesem, czy nie i zadecydować, czy ją przesłać, usunąć z kolejki, czy cokolwiek innego.

Prawdopodobnie powinniśmy także umożliwić koñcowym użytkownikom przesyłanie ich własnych łat do opiekuna i dać im możliwość konfigurowania systemu na serwerze, tak by mogli mieć dokładnie to samo, co opiekun.

Najważniejszą częścią jest tu to, że system powinien zmiejszyć pracę opiekunów, bo odpowiada on na tysiące maili i sprawdza czy łaty są w porządku i robi to bez przerwy. (Myślę, że to powinno być relatywnie łatwe). To musi być łatwe do wykorzystania, zarówno dla opiekunów jak i dla użytkowników.

Mam trochę rozsądnych, miłych skryptów w pythonie, które działają tak jak część odpowiedzialna za budowanie jądra, i trochę, w sumie obrzydliwych skryptów, które działają jako serwer webowy. Krótki opis jest dostępny tu.

http://altus.drgw.net/description.html

Ochotniczo oddaję te skrypty razem z pewną ilością czasu, którą mogę poświęcić na ,,prawdziwą'' pracę ;)

patchbot@nl.linux.org

Możecie zapisać się na tę listę wysyłając na adres listar@nl.linux.org list o treści ,,subscribe patchbot''.

Jak tylko się tym zajmę, to pod adresem http://patchbot.nl.linux.org/ powinna się też znaleźć jakaś treść (chyba że ktoś inny się tym zajmie)

Wygląda nieźle, oprócz tego, że nigdzie nie napisano, dla której wersji jądra wyprodukowano tę łatkę. To bardzo często jest dość ważne ;)

Teraz, jeśli chcesz to zautomatyzować, to proponowałbym dodać jedną sekcję między wyjaśnieniem a łatką: wynik ,,diffstat'' łatki. Nie ma to dużego znaczenia w tym przypadku, bo oczywiście łata jest wystarczająco mała, że przewinięcie ekranu pokazuje o co chodzi, ale...

Sugerowałbym także, że cokolwiek automatycznego, co miałoby aktywować łatkę, powinno pytać o jej temat i wymuszać by był dłuższy niż 12 znaków ;)

Warte uwagi przy automatyzacji byłyby sumy md5 lub podobne (by sprawdzać, że udało się bez szwanku przetransportować łatkę przez system mailowy). Podpis pgp byłby nawet lepszy, oczywiście - szczególnie użyteczny, że, jak podejrzewam, dobrze by było robić cc na pewną patch-list, a posiadanie identyfikacji wysyłającego jest zawsze dobrym pomysłem w takich przypadkach.

Hmm.. To mogłoby zadziałać, jednakże spodziewam się, że najbardziej zagorzali zwolennicy rozwiązañ embedded są właśnie tymi, którzy mogą czerpać z ramfs najwięcej korzyści. To był z pewnością powód, dla którego istnieje..

Zobaczymy. Skoñczy się na tym, że będziemy używać ramfs do wstępnego butowania (np. do ,,tar.gz->ramfs'' etapu butowania), więc przerabianie tego na __init może nie być praktyczne z innych powodów. Musielibyśmy rozładować to nie po etapie __init, lecz po tym, jak pierwszy system plików root staje się nieużywany (co może zdarzyć sie później, zależnie od tego, co ludzie wrzucą do systemu plików).

Ech. Myślę, że musiałem Ci ją dać dawno temu i nigdy mi jej nie oddałeś, ty podstępny draniu ;)

Wizja, tak przy okazji, jest taka, żeby na tyle poprawić warstwę żądañ, abyśmy mogli obyć się bez półwarstwowych podejść SCSI/IDE i przetworzyć urządzenia blokowe w _tylko_ sterowniki urządzeñ.

Na przykład, ide-scsi leci w tę wielką dziurę w niebie: warstwa SCSI już nie obsługuje specjalnych żądañ ioctl, ponieważ wyższe warstwy będą wystarczająco elastyczne, abyś mógł po prostu przekazać żądanie w dół zwykłego potoku.

(W tej chwili możesz coś takiego zobaczyć w block_ioctl.c - jakkolwiek tylko część ioctl została przetworzona, masz ogólne pojęcie. Jestem raczej zdziwiony i zaskoczony, że nikt jeszcze nie komentował tej części).

Ostateczny wynik (mam taką nadzieję) jest taki, że możemy pozbyć się kilku par znajdujących się w warstwie blokowej. ide-scsi to tylko najoczywistsza dziwaczna para - rzeczy, takie jak "sg.c" w ogólności są raczej okropne. Jest bardzo mało _SCSI_ w sg.c - naprawdę to dotyczy przesyłania poleceñ w dół, do urządzeñ blokowych.

Powodem, dla którego chcę pozbyć się par, jest to, że na koñcu stają się wielkimi kotwicami hamującymi rozwój: możesz stworzyć czysty sterownik, który nie zależy od wyższej warstwy SCSI (i ludzie takie tworzą, dla rzeczy takich jak DAC itd.), ale kiedy tak robisz, tracisz _całą_ wspomagającą infrastrukturę, nie tylko nadęcie. A to jest smutne.

(I to dlatego rzeczy jak ide-scsi istnieją - IDE w rzeczywistości nie chciało być sterownikiem SCSI, ale ludzie _chcieli_ mieć możliwość użytkowania kilku ogólnych procedur obsługi oferowanych przez warstwę SCSI. Nie mógłbyś tak po prostu radośnie używać części, które chciałeś).

Inna część przepisywania bio polega na usunięciu kolejnej pary: pomiędzy ,,struct buffer_read'' (używaną do ograniczonego rodzaju zarządzania pamięcią przez ileś systemów plików) i faktu po prostu robienia WE/WY.

Zwykłem myśleć, że możemy po prostu relegować ,,struct buffer_head'', aby _stała się_ bytem WE/WY, ale wychodzi, że znacznie łatwiej będzie po prostu oddzielić WE/WY i to dlatego teraz masz oddzielną strukturę ,,bio'' dla blokowego WE/WY, a buffer_head używa tego do wykonania pracy.

Andre, wiem, że martwisz się niskopoziomowymi sterownikami, ale:

• dawno temu już zauważyłem, że nie potrafimy się komunikować, dlatego Jens jest osobą odpowiedzialną za sterowniki urządzeñ blokowych. Musisz z tym żyć.

• Osobiście nie sądzę, abyś potrafił stworzyć dobry sterownik, nie mając rozsądnych interfejsów, a nie mieliśmy ich.

• Sterowniki sieciowe, na przykład, znacznie się poprawiły i nie mają _niemal_ tej liczby problemów, co sterowniki urządzeñ blokowych. Częściowo, to oczywiście dlatego, że są prostszym problemem, lecz właśnie dlatego, że były prostsze, można było je zmienić. Zmiany infrastruktury w sieci w serii 2.3.x naprawdę pomogły sterownikom.

Zauważ też, że ,,Jens'' i ,,komunikacja'' są bardzo istotne. Jeśli masz jakieś łatki, rozmawiaj, proszę, z Jensem, powiedz mu o kłopotach, bo wiem, że z nim ja mogę się dogadać.

Dodałem obsługę sterownika audio SiS7012 do sterownika audio i810. Na mojej płycie głównej ECS K7S5A odtwarzanie działa doskonale. W niektórych przypadkach zapisywanie powoduje pad systemu, ale pracuję nad tym.

BTW, czy ktoś ma dane do tego układu? W tej chwili sterownik jest oparty na fakcie, że OSS wykorzystuje ten sam sterownik dla układów i810 i SiS7012 oraz na eksperymentach.

To dobra wiadomość. Chciałbym tu dodać coś nieco mniej lamerskiego niż ,,ja też''...

Poza tym, że jest to podstawowe narzędzie, którego używam codziennie, sądzę że UML ma duży potencjał, jako ,,doskonałe więzienie''. Gdy UML się rozpowszechni, zaczniemy dostrzegać wiele interesujących aplikacji takich, jak symulacja klastrów czy ,,Bąbelki Linuksowe'' pod Windows.

Sądzę, że wykonujesz doskonałą pracę opiekując się UML-em poza-głównym-drzewem przez ponad rok, bez prawie jakiejkolwiek pomocy i mam nadzieję, że taki stan rzeczy nie potrwa już zbyt długo.

• Poprawka potencjalnego uszkodzenia przy pomocy vmalloc (Ralf Baechle)
• Małe poprawki do kompilacji na PPC (Tom Rini)
• Poprawki do uruchamiania zImage (Kalev Soikonen)
• Poprawka przy odczycie EIO przez NFS (Trond Myklebust)
• Aktualizacja sterownika raid 3ware (Adam Radford)
• Usunięty wyścig page_alloc (Andrea Arcangeli)
• Aktualizacja opiekunów USB (Greg Kroah-Hartmann)
• Poprawka clipcount=0 w bttv (Solar Designer)
• Poprawki różnych błędów w sterowniku eepro (Aris)
• Poprawki w obsłudze kolejki Sym53c8xx (Gerard Roudier)
• Aktualizacja dokumentu o zgłaszaniu sterowników (Michal Svec)
• Optymalizacja wydajności 8139too (Jens David)
• Poprawka w obsłudze dowiązañ w procfs (Solar Designer)
• Przeniesienie poprawki przepełnienia bufora przy SEM_UNDO w 2.4 (Leonid Igolnik)
• Poprawki VM86 (Manfred Spraul)
• Poprawki kompilacji na Alphie (Kim Heino)

Po spędzeniu kilku chwil na openprojects.net, zdecydowałem się stworzyć nowe drzewo 2.4. Sądzę, że istnieje potrzeba szybko rozwijającego się drzewa podobnego do -ac, więc oto jest. Testujcie do woli. Dołączam patch-2.4.17-mjc1.bz2. Nowe wersje są dostępne pod adresem http://iamnotanimatedtoexplode.com/patches/mjc. W tej chwili łata zawiera:

Łata z odwrotnym mapowaniem #9 (Rik van Riel)
Łata wywłaszczająca jądro (Robert Love)
Łata usuwająca niektóre blokady (Robert Love)
Dodatkowa pozycja w /proc z afinicznością CPU (Robert Love)
Zasilanie entropii /dev/random z urządzeñ sieciowych (Robert Love)
Programowe zamrażanie komputera (Gabor Kuti?)
Szeregowanie czasu rzeczywistego dla Linuksa (?)
Aktualizacje IDE (Andre Hedrick}

Docelowo chciałbym, aby łata była rozwijana (przypuszczalnie przy użyciu bk) przez osoby z #kernelnewbies.

Linus powiedział niegdyś, że wiele drzew to dobra rzecz. Mimo to, będę starał się być tak blisko 2.4.x, jak to możliwe :)

Chciałem powiedzieć, że od 2.4.17 z łatą wywłaszczającą jądro, Linux, przynajmniej w moim przypadku, zdaje się działać tak dobrze, jak 2.2.19, w stosunku do interaktywnego użycia i niezawodności.

2.4.17 cały czas ma problemy przy uruchamianiu aplikacji, które wymagają olbrzymich ilości pamięci, i które działają bez problemu na 2.2.19. (Serwery z 2GB RAM z aplikacjami wymagającymi ponad 3GB.)

Wypróbowałem łatę rmap-10 z nowym VM i, przy zwykłym obciążeniu mojej stacji roboczej, komputer za każdym razem się wieszał. Wydaje mi się, że ilość dostępnej pamięci dramatycznie spadała przed zwisem. Aplikacja, o której wspominałem, przechodziła przez różne dziwne stany.

Bez wątpienia łata z wywłaszczaniem i rmap-10 są niezgodne ze sobą, ale nie zamierzam porzucić walki z łatą wywłaszczającą jądro.

Tak, czy siak, 2.4.17 z wywłaszczaniem działa całkiem zacnie.

Podejrzewam, że rmap-10 nie jest łatą wywłaszczającą. Jeśli masz czas/jesteś zainteresowany przetestuj obciążenie tylko z rmap10a (poprawione rmap10). To może dać ciekawe wnioski na temat, która łata psuje wszystko.

Podobnie, łaty zmniejszające opóźnienia, które zdają się dawać lepsze wyniki niż łaty wywłaszczające jądro, przypuszczalnie spowodują mniej problemów, ponieważ one, tak naprawdę, nie zmieniają semantyki systemu w ten sposób.

W rmap-10 jest głupi błąd logiczny, który naprawiłem w rmap-10a. Godzinę po opublikowaniu rmap-10, znalazł go Andrew Morton.

W wakeup_kswapd() procesy użytkownika zasypiają jeśli VM jest _bardzo_ zajęty *i* procesy użytkownika maja takie same opcje GFP, jak kswapd, tak aby mogły poczekać, aż kswapd wykona swoją pracę.