Kwn1

Kernel Weekly News 1 (22-IV-2007 - 29-IV-2007)

Witaj w pierwszym odcinku tygodnika wiadomości ze świata jądra Linux. Jest on wzorowany na wydawanym kiedyś Kernel Traffic i będę w nim zamieszczał skróty ciekawszych dyskusji toczących się na Linux Kernel Mailing List. Teksty nie są tłumaczone dosłownie, skupiam się raczej na przekazaniu sensu danej wypowiedzi, czasami też w nawiasie umieszczam krótki komentarz, który ma za zadanie rozjaśnić niektóre sformułowania/aluzje/etc.

Miłej lektury!

1 Linux 2.6.16.49

Adrian Bunk powiadomił o wydaniu czterdziestej dziewiątej wersji swojego stabilnego drzewa Linuksa, przeznaczonej dla ludzi oczekujących niezawodności i niezmienności kodu jądra w dłuższym okresie czasu. Osiem miesięcy temu Adrian przejął opiekę nad wersją 2.6.16 i od tego czasu wydał dwadzieścia dwie stabilne wersje, które z reguły poprawiały błędy związane z bezpieczeństwem oraz naprawiały poważniejsze problemy znalezione w późniejszych wydaniach Linuksa.

2 W sprawie Reiser4

Eric Hopper odważył się poruszyć temat systemu plików Reiser4 (napisałem "odważył", bo z reguły robią to ludzie, którym zależy na dużym flame war ;)): „Wiem, że całą sytuację skomplikował proces Hansa Reisera, ale jestem ciekawy jaki jest aktualny stan. Czy Reiser4 ma szansę w najbliższym czasie na włączenie do Linuksa? Czy jest jakieś miejsce, gdzie mógłbym znaleźć odpowiedź na to pytanie bez marnowania łącza?”. Lee Revell zapytał czy przeszukał archiwum LKML.

Z kolei Rik van Riel napisał „To już wcześniej było skomplikowane. Wiele funkcji Reiser4 np. funkcjonalność wtyczek, technicznie miałaby sens jako rozszerzenie VFS (wirtualny system plików), jednak dla Namesys ważne jest, aby to była funkcja Reiser4. To prowadzi do pata.”. Na pytanie o szanse włączenia w najbliższym czasie systemu plików Reiser4 do drzewa surowego odpowiedział krótko: „nie liczyłbym na to”.

William Heimbigner zapytał czy kryterium nie powinna być stabilność, wspomniał również o tym, że pomiary wydajności sugerują, że Reiser4 to dobry system plików. „Nie widzę powodu, dla którego coś takiego jak infrastruktura wtyczek powinna być brana pod uwagę.” - napisał - „Jeżeli to działa wystarczająco dobrze, aby być oznaczone jako eksperymentalne, to dlaczego nie może zostać włączone?”. Wspomniał też o tym, że każdorazowo po wydaniu nowego jądra musi ręcznie nakładać łatki, aby korzystać z Reiser4. Na pierwsze pytanie Rik odpowiedział następująco „Jest dużo ważnych rzeczy, np. wola opieki nad kodem po tym jak zostanie on włączony lub przynajmniej doprowadzenie go do takiego stanu, w którym społeczność będzie się chciała nim opiekować gdy jego autorzy przestaną o to dbać”. Poruszył również problem porzucenia opieki przez Namesys nad systemem ReiserFS po tym jak został włączony do jądra surowego. Następnie przedstawił Williamowi trzy opcje do wyboru - „Masz w zasadzie trzy opcje do wyboru: 1)nakładać łatki za każdym razem, gdy przygotowujesz nowe jądro 2)używać innego systemu plików 3)zostać nowym opiekunem Reiser4 i doprowadzić go do stanu w którym Linus mógłby go zaakceptować
Następnie dyskusja zeszła na temat: „jakie warunki muszą zostać spełnione, aby Reiser4 został włączony do drzewa surowego?”, którą William Heimbigner podsumował w trzech punktach „1) Reiser4 potrzebuje opiekuna. 2) Kod systemu plików musi zostać wyczyszczony tak, aby spełniał linuksowe standardy. 3) Dopóki dwa pierwsze warunki nie zostaną spełnione Reiser4 nie zostanie włączony do mainline.”.

W tym momencie do dyskusji włączył się Andrew Morton: „Inżynierowie z Namesys kontynuują prace nad Reiser4 a ja kontynuuje odbieranie łatek. Mogę powiedzieć, że aktualnie głównymi przeszkodami stojącymi na drodze do włączenia Reiser4 są: a) aktualnie deweloperzy nie proszą o jego włączenie (o ile się orientuję) i b) inni deweloperzy nie przeglądają kodu”. Eric Hopper zapytał „Czy wystarczyłoby, gdyby ktoś inny zaczął prosić o włączenie R4 do drzewa surowego i odpowiadał na wszystkie prośby poprawy jakości kodu? W uproszczeniu – gdyby ktoś zrobił forka? Czy też muszą to być inżynierowie z Namesys?”.

Andrew Morton odpowiedział następująco: „To nie w tym jest problem – ludzie z Namesys odpowiadają na życzenia innych i potrafią dobrze z nimi współdziałać, ale od ponad roku nie otrzymali żadnej prośby o zmienienie czegokolwiek w kodzie.

Ja płynę tym samym statkiem co inni – od wieków nie przeglądałem kodu Reiser4. Aktualnie nie mam żadnej listy pozostałych do załatwienia spraw technicznych.

Aby ruszyć sprawę do przodu potrzebujemy pewnego zrywu, ludzie muszą zacząć przeglądać kod i testować go, dystrybutorzy również muszą zacząć poważnie o tym myśleć. Możemy to zrobić – będzie to wymagało od ludzi z Namesys (i ode mnie) rozpoczęcia poważnej dyskusji nad włączeniem kodu do drzewa surowego.

Możemy też przenieść cały kod Reiser4 do kernel/sched.c – to chyba teraz pochłania uwagę. (ostatnie zdanie, to żartobliwy komentarz Mortona do niedawnej wojenki schedulerowej ;))”

Andi Kleen powiedział: „Mam wrażenie, że wiele negatywnych komentarzy odnosiło się do interfejsów użytkownika (takich jak wywołanie systemowe sys_reiser4 czy niekompatybilne EA (rozszerzone atrybuty)).

Uważam, że dobrą strategią włączenia do mainline, byłoby wydzielenie „rdzenia Reiser4”, który byłby po prostu systemem plików bez nowych interfejsów.

Przejrzenie tego kodu powinno pójść gładko, ponieważ ludzie mogliby się skoncentrować na detalach technicznych.”

Na list Andiego odpisał Edward Shishkin z Namesys „sys_reiser4 oraz meta interfejsy zostały usunięte (aktualnie drzewo -mm ich nie zawiera).

Uważam, że obecny kod Reiser4 jest dokładnie tym „rdzeniem”, który odpowiada wyłącznie VFS. Popularna opinia jakoby interfejs wtyczek miałby większy sens w kodzie VFS jest nieporozumieniem, ponieważ wtyczki są bezpośrednio związane z rozmieszczeniem danych na partycjach Reiser4.

Jest wiele aspektów w których architektura wtyczek jest użyteczna. Spróbowałem opisać jeden z nich – wsteczną kompatybilność, którą można osiągnąć przy minimalnym wysiłku: http://dev.namesys.com/Version4.X.Y Jeżeli będzie to wymagało więcej komentarzy, to rozszerzymy dokumentacje.

Dalsze komentarze:
1 Dlaczego aktualnie deweloperzy Namesys nie proszą o włączenie?
Ponieważ jeszcze nie wykonali wszystkich rzeczy, które mają na swoim ToDo: http://pub.namesys.com/Reiser4/ToDo Najważniejszymi problemami są rozszerzone atrybuty i wsparcie dla blocksize != pagesize (przypadek, gdy rozmiar bloku na dysku nie jest równy rozmiarowi strony pamięci). Myślę, że dodanie rozszerzonych atrybutów zajmie nam w przybliżeniu miesiąc ciągłej pracy. Nie mam pewności co do wsparcia dla blocksize.

2 Kto będzie się tym opiekował?
Aktualnie jest dwóch pracowników Namesys pracujących głownie z zapału. Podzielcie ich na dwa systemy plików, dodajcie wielu ludzi, którzy naprawdę pomagają rozwiązywać problemy.

Musimy więc ocenić jak dramatyczna jest sytuacja z Reiser4 (mile widziani eksperci). W najgorszym wypadku (brak funduszy) mam nadzieję przeznaczyć na to w przybliżeniu 25% czasu mojej pracy.”

Andi Kleen odpowiedział Edwardowi w sprawie rozszerzonych atrybutów i rozmiaru bloku: „Rozważyłbym obie rzeczy jako opcjonalne. Mamy w drzewie różne systemy plików, które nie wspierają którejś z tych rzeczy (np. JFS wspiera tylko 4K bloki a OCFS2 nie ma wsparcia dla rozszerzonych atrybutów). Te rzeczy nie powinny zablokować włączenia.”

Dalsza część dyskusji sprowadzała się głównie do omawiania problemów technicznych występujących przy używaniu systemu plików jak bazy danych.

3 2.6.21-rc7 znane regresje (v2)

Adrian Bunk podesłał zaktualizowaną listę piętnastu regresji, które powinny być naprawione przed wydaniem Linuksa 2.6.21 (termin „regresja” odnosi się do błędu, który został wprowadzony w aktualnej wersji rozwojowej). W dwóch przypadkach jest już dostępna łatka, w jednym tylko wersja wstępna. Cztery przypadki są debugowane a status dziewięciu pozostałych nie jest znany.

4 Planista CFS

Ingo Molnar wydał wersję -v6 planisty CFS (Completely Fair Scheduler): „Głównym celem CFS jest implementacja „wysokiej jakości planisty CPU dla desktopów” tak dobrze, jak to jest tylko technicznie wykonalne.

Łatka CFS na 2.6.21-rc7 lub 2.6.20.7 może zostać pobrana z tego samego co zwykle miejsca
http://redhat.com/~mingo/cfs-scheduler/

Odzew po wydaniu wersji v5 był bardzo duży (dzięki, proszę o dalszy odzew), więc -v6 poprawia wiele błędów oraz zawiera dużo ulepszeń:
* właściwość: zwiększenie wartości ziarnistości wywłaszczenia na systemach SMP. Idea i kod pochodzi z planisty SD napisanego przez Cona Kolivasa, użyczonego za jego pozwoleniem. Dzięki Con!
* poprawka dokładności sched_clock(). Powinno to rozwiązać zgłaszane problemy z interaktywnością na systemach, które zmieniają częstotliwość procesora (głównie laptopy)
* optymalizacja ustawień domyślnych: zmiana domyślnego parametru nice procesu X z -19 na -10, oparte na raportach testerów. (Dalej może być za dużo, więc dalsze komentarze będą potrzebne)
* debugowanie: SysRq-T pokazuje również zawartość /proc/sched_debug – użyteczne do generowania zrzutu wszystkich danych związanych ze stanem planisty za jednym zamachem
* debugowanie: SysRq-Nice teraz normalizuje zadania o ujemnych poziomach nice i resetuje stan CFS
* debugowanie: /proc/sched_debug zostało poszerzone o kilka dodatkowych informacji odnośnie zegara, aby ułatwić debugowanie problemów związanych z jego niestabilnością”
(lista zmian została przycięta do tych, które uznałem za ciekawsze)

Dalsza część dyskusji dotyczyła rozwiązywania problemów z planistą, na jakie natrafili testujący go ludzie.

5 Linux 2.6.21

Linus Torvalds napisał: „Jeżeli celem dla 2.6.20 było wydanie stabilnej wersji (i taka była), to dla 2.6.21 celem było przeżycie wielkich zmian związanych z timerami i kilkoma innymi niespodziankami (np. mieliśmy na tyle mało szczęścia, że trafiliśmy na poprzednio nieznany błąd sprzętowy wywołany aktualizacją jednego ze ethernetowych sterowników etc.)

A więc mieliśmy ponad dwu i pół miesięczny cykl rozwojowy, wprawdzie nie najdłuższy, ale i tak dłuższy niż oczekiwałem i jaki w rzeczywistości powinien być. Jak zwykle chciałbym podziękować Adrianowi (i ludziom, którzy załapali się na jego listę) za utrzymywanie wszystkich na bieżąco z regresjami – ciągle jest kilka punktów na liście, ale doszło do miejsca w którym nawet nie wiemy, czy to są to prawdziwe regresje, a opóźnianie wydania w niczym tu nie pomoże.
[..]”

Adrian Bunk zrobił krótkie podsumowanie znanych regresji:
„Liczba różnych znanych regresji w porównaniu z 2.6.20 w czasie wydania 2.6.21:
14

Liczba różnych znanych regresji w porównaniu z 2.6.20 w czasie wydania 2.6.21, które zostały zgłoszone w marcu i wcześniej:
8

Liczba różnych znanych regresji w porównaniu z 2.6.20 w czasie wydania 2.6.21, dla których były dostępne łatki w czasie wydania 2.6.21[1]:
3

Czego NIE będę robił:
Marnował swojego czasu na śledzenie regresji w 2.6.22-rc.

Mamy wielu testerów, lecz nie mamy wystarczająco wielu deweloperów, którzy by się zajmowali błędami.

Jeżeli byśmy brali na serio „brak regresji”, to cykl rozwojowy trwałby 4-5 miesięcy, przez brak deweloperów zajmujących się poprawianiem dostrzeżonych błędów. To powinno być OK, jeśli zapobieganie regresjom byłoby ważniejsze niż szybkie przeskoczenie do następnego dwu tygodniowego okna na włączanie nowych błędów do jądra.

Wydanie jądra z taką ilością znanych regresji jest obraźliwe dla wielu ludzi, którzy poświęcają czas na testowanie jąder -rc.”

Na słowa Adriana o porzuceniu śledzenia regresji odpowiedział Dave Jones: „Mam nadzieję, że to jeszcze raz przemyślisz. Gdybyś tego nie robił, to w mojej opinii sprawy wyglądałyby dużo gorzej.

W każdym bądź razie, dzięki za wykonywanie tej niewdzięcznej roboty, która nie przysparza ci tak wielu kernel groupies jak przepisywanie planisty procesów, ale jest równie ważna (jeśli nie ważniejsza).”

Wielu deweloperów poparło apel Dave Jonesa o to, żeby Adrian przemyślał jeszcze raz swój zamiar.

Adrian wysłał małą klaryfikacje: „Zdaje sobie z tego sprawę, że moja praca przynosi pewne efekty, zdaje sobie również sprawę z tego, że jest ona doceniana – nikt nie musi mi tego powtarzać.

Problem jest w tym, że nie jestem usatysfakcjonowany jej wynikami.

Linus powiedział, że 2.6.20 było stabilnym wydaniem. Mam wrażenie, że przynajmniej dwie z mojej listy regresji powinny być poprawione przed wydaniem 2.6.20.

Obie zostały naprawione w linii -stable, ale pamiętam, że jeden z dość doświadczonych opiekunów jądra natrafił na jedną z nich po wydaniu 2.6.20 i spędził pół dnia próbując wykryć co wywołuje błąd – moja odpowiedź była następująca „znana, niepoprawiona regresja, pierwszy raz zgłoszona ponad miesiąc temu”.

Jest konflikt pomiędzy Linusem próbującym wydawać jądro co dwa miesiące i wydawaniem z kilkoma regresjami.

Próba zapobiegania regresjom w najgorszym przypadku może się skończyć dwunastoma wersjami -rc i czteromiesięcznym cyklem. Jeżeli skupiamy się na zapobieganiu regresjom, to musi to zostać zaakceptowane.

Poważne opóźnienie następnego okna na włączanie błędów przez nienaprawione regresje może mieć pozytywny wpływ, bo deweloperzy zaczną się interesować naprawianiem aktualnych błędów aby szybciej wprowadzić swoje nowe błędy i nową funkcjonalność do drzewa Linusa.

Zero regresji nigdy nie będzie realnym celem (ponieważ wiele błędów może nie być zgłoszona podczas -rc), jednak w mojej opinii możemy się bardziej postarać niż to robiliśmy podczas 2.6.20 i 2.6.21.

To tylko moje osobiste opinie, inni ludzie mogą uważać wynik prac nad jądrami 2.6.20 i 2.6.21 za udany.

Nie jestem usatysfakcjonowany rezultatami, a świat się nie zatrzyma, gdy przestane śledzić regresje w 2.6.22-rc.”

Linus odpowiedział: „Nie. Liczba regresji zwiększa się podczas dłuższych cykli. Ich liczba nie maleje.

Dlatego mamy serię -stable. Powodem tego jest to, że proces rozwoju jądra może odbywać się na trzy sposoby:
(a) Długie cykle rozwojowe z dwoma pod przypadkami:
(a1) Olbrzymie zmiany (np. „długie serie rozwojowe”). To jest coś co już kiedyś mieliśmy. Nie ma nawet możliwości na śledzenie regresji, ponieważ wszystko się za bardzo zmienia.
(a2) Ograniczony rozwój, po prostu rozciągnięcie „fazy stabilizacji”. To najzupełniej na świecie nie działa. To jest niezgodne z ludzką naturą. Ludzie nudzą się i zaczynają dyskutować o ezoterycznych problemach planistów, które tak naprawdę nie są regresjami.
(b) Krótkie i rozchwiane cykle wydań: utrzymywanie niskiej ilości zmian (jak w a2), ale należy rozpoznać kiedy staje się to nietwórcze i wtedy wydać, aby ludzie zajmujący się -stable się tym zajęli. Zanim większość deweloperów (którzy i tak nie pracowaliby nad stabilnym jądrem) wpadnie w frustracje.

Tak, wybraliśmy (b). Czasami wydajemy „W ogóle nie przyjmuje w połowie zrobionych rzeczy” jak 2.6.20.

Próba zapobiegania regresjom w najgorszym przypadku może się skończyć dwunastoma wersjami -rc i czteromiesięcznym cyklem. [..]

Nie. Ignorujesz deweloperską rzeczywistość. Wygląda ona tak, że musisz wszystko wyważyć. Jeśli masz czteromiesięczny cykl wydawniczy, w którym trzy i pół miesiąca tylko czekasz na raporty od testerów, to nic nie będziesz miał zrobione. Sfrustrowani deweloperzy znajdą sobie inne zajęcie.

Nie jestem usatysfakcjonowany rezultatami, a świat się nie zatrzyma, gdy przestane śledzić regresje w 2.6.22-rc.[..]

Prawda. Wprawdzie smutnym jest, że nie chcesz ich dalej śledzić. Były bardzo użyteczne. To, że uważasz inaczej wynika z tego, że masz nierealistyczne oczekiwania i uważasz, że ludzie od -stable nie powinni mieć nic do roboty.

Opiekujesz się 2.6.16 – nie widzisz co się stanie, gdy zdecydujesz że „zero regresji” jest celem? Musisz zatrzymać rozwój. Ten pomysł może wydawać się dobry na krótką metę, jednak w dłuższym okresie czasu jest totalną katastrofą (nawet nie w bardzo długim: wystarczą dwa do trzech cykli), ponieważ gdy jesteś w fazie „poprawiania regresji”, ludzie ciągle tworzą, a ty tylko stwarzasz problemy dla następnego wydania przez zbyt długie wstrzymywanie.

To jest prawdziwa rzeczywistość: 5 do 7 milionów linii zmian w wydaniu co dwa do trzech miesięcy. Czy naprawdę uważasz, że te rzeczy zatrzymają się przez proces wydania? Nie. Jeśli rozciągniesz cykl do 4+ miesięcy, w zamian będziesz miał 10-15 milionów linii zmian (lub bardziej prawdopodobne, stracisz deweloperów i będziesz miał tylko 2 miliony linii, a trzy lata później masz jądro, które jest przestarzałe i już nie nadaje się do użytku. Popatrz na inne Uniksy).

Innymi słowy, jest powód dla którego mamy taki model rozwoju. Mamy „zwariowane drzewa deweloperskie” (znane jako -mm i różne inne), mamy „drzewo rozwojowe” (znane jako drzewo Linusa) i mamy drzewo -stable. Jeśli stabilne drzewo ma tuzin znanych problemów, to będą sobie musieli z tym poradzić w ciągu najbliższych dwóch miesięcy, to jest w porządku. To jest zadanie drzewa stabilnego.

Pomożesz im z 2.6.22-stable, jeżeli dalej będziesz tworzył swoją listę. Nawet gdy to jest zaprojektowane tak, że nie schodzi do zera.

Podejrzewam, że podszedłeś zbyt optymistycznie do faktu, że 2.6.20 było bardzo łatwym wydaniem. To zostało tak zaprojektowane. Uważasz, że było złe lub średnie, ale to jest wina twoich nierealistycznych oczekiwań, a nie dlatego, że było coś złego w 2.6.20.”

Dalsza dyskusja skupiła się na przydatności bugzilli (lub jej braku).

Ten numer KWN został przygotowany przez Michała Piotrowskiego.

O ile nie zaznaczono inaczej, treść tej strony objęta jest licencją Creative Commons Attribution-Share Alike 2.5 License.