Download: NewsKernel

NOWOŚCI
Jądro
NOWOŚCI W JĄDRZE
DEVFS
W ostatnich dniach Greg Kroah-Hartman
podjął kilka prób usunięcia systemu plików
DevFS z drzewa 2.6, okazało się to jednak
trudne. Próbował najpierw wysłać łatę, która
całkowicie usunęłaby ten system plików, ale
zdaniem niektórych – zwłaszcza tych, którzy
na co dzień polegają na DevFS – było to zbyt
agresywne posunięcie. Spróbował więc z patchem, który tylko wyłączałby DevFS, planując usunięcie go całkowicie, jeśli nie pojawiłyby się zbyt głośne protesty. Dla wielu osób to
także było zbyt ekstremalnym rozwiązaniem.
Ostatecznie Greg stworzył ndevfs, wersję „nano” DevFS, która miałaby zastąpić wersję pełną i – oby – zadowolić zatwardziałych użytkowników tego systemu. Okazało się jednak,
że sam Greg nie potrafił pogodzić się z takim
kompromisem i zdecydował o zaprzestaniu
prac nad łatą. Uważał po prostu, że dynamiczny system plików/dev nie należy do jądra.
Problem pozostał nierozwiązany. Greg powiedział w pewnym momencie, że „DevFS jest
niepotrzebny, zły i zostanie usunięty z jądra”.
Jednym z najbardziej interesujących
aspektów całej dyskusji jest fakt, że nikt
nie wspomina wiele o utworzonym przez
samego Grega (i oficjalnym) zamienniku
DevFS, udev, napisanym właśnie po to, aby
zastąpić DevFS. Wygląda na to, że DevFS,
mimo swoich wad, to coś, czego nikt inny
nie był w stanie przez cały ten czas osiągnąć
lub skutecznie zastąpić, więc jego ostatecznemu usunięciu nie będzie prawdopodobnie towarzyszyć żadne rozwiązanie, które
udostępniałoby użytkownikom równoważne funkcje.
Richard Gooch, autor DevFS, znalazł się
pod obstrzałem niemal natychmiast po
wprowadzeniu tego narzędzia. Jego styl
programowania różnił się od stosowanego
przez innych programistów jądra, Richard
obstawał jednak przy tym, że jest to właściwy sposób. Jego cel – stworzenie dynamicznego, działającego w przestrzeni jądra zamiennika katalogu/dev – także był od samego początku uważany za wyjątkowo kontrowersyjny, zwłaszcza przez programistów
takich jak Alexander Viro, opiekun VFS.
Przez lata tu i tam wybuchały spory: Alexander narzekał na problemy związane
z kodem Richarda, Richard zaś oskarżał
Aleksandra o to, że nie określa jasno, na
czym te problemy polegają.
Linus Torvalds rozstrzygnął ostatecznie
tę kwestię, włączając DevFS do swojego oficjalnego drzewa. Przez krótką chwilę wyglądało na to, że Richard jest zwycięzcą
w sporze; okazało się jednak, że Linus miał
własne wizje funkcji DevFS. Kilka z nich
stało w rzeczywistości w sprzeczności z intencjami Richarda. Tymczasem zaś coraz
większa liczba użytkowników zaczęła korzystać z narzędzia na co dzień, dzięki czemu znacznie się ono rozwinęło. Wielu czołowych autorów jądra nadal uważa, że jest
to jedna z najgorszych podjętych przez Linusa decyzji. Alexander oświadczył pewnego dnia, że DevFS zawiera „nienaprawialne
wyścigi (race conditions)”, a osąd ten przylgnął do systemu plików na dobre. Widząc,
co się święci, Richard zrezygnował w końcu
z całego projektu i wycofał się całkowicie
z prac nad jądrem. Greg, jeden z najsurowszych krytyków DevFS, przejął projekt, zamierzając zakończyć go ostatecznie, ale
najwyraźniej przekonał się, że jest to trudniejsze, niż mu się wydawało.
NOVELL DEBUGGER
Pracownicy firmy Novell stworzyli nowy
debugger jądra na licencji Open Source
(NLKD), a na Ottawa Linux Symposium zaprezentują poświęconą mu pracę. Twórcy jądra nie powitali jednak tego projektu z otwartymi ramionami. Jest już kilka debuggerów
Open Source (KGDB i KDB), których Novell
– przed stworzeniem własnego – nie przetestował dokładnie. Wygląda na to, że istniejące debuggery mają pewne funkcje, których
brakuje w NLKD. Debugger Novella oferuje
tylko łaty na konkretne wersje jądra oferowane przez poszczególnych dystrybutorów, co
utrudnia innym testowanie go. Relacje tych,
którzy korzystali już z programu, nie są
szczególnie entuzjastyczne. Z drugiej jednak
strony, jak podkreślają niektórzy, Novell jako
firma uczynił krok we właściwym kierunku,
a różni programiści zaczęli już formułować
wskazówki i sugestie dotyczące usprawnienia
NLKD.
Linus Torvalds przez długi czas traktował
debuggery jądra podejrzliwie, mówiąc, że
promują niechlujną praktykę debuggowania.
Uważa, że najlepszym sposobem usuwania
błędów z kodu kernela jest zrozumienie jego
działania, zbadanie kodu źródłowego i wydedukowanie, na czym polega problem.
12
WWW.LINUX-MAGAZINE.PL
NUMER 20 PAŹDZIERNIK 2005
Używanie debuggera, powiedział, pozwala
na znajdowanie błędów, ale nie skłania do dokładnego zrozumienia kodu, przez co bardziej prawdopodobne staje się wysyłanie byle
jakich poprawek. Ogromna liczba programistów jądra jest jednak innego zdania, a sam
Linus wyraża chwilami chęć zawarcia kompromisu dotyczącego tej kwestii.
NOWOŚCI
GIT
Wygląda na to, że stworzone przez Linusa
Torvaldsa narzędzie do kontroli wersji, git,
faktycznie – jak obiecywano – staje się jednym z najbardziej niesamowitych przykładów
rozwoju oprogramowania Open Source od
czasów samego jądra Linuksa. Postępy prac są
po prostu zdumiewające – nad gitem pracują
setki programistów, powstało mnóstwo związanych z nim zewnętrznych projektów, dokumentacji, przeglądarek graficznych i stron
WWW opisujących gita lub wykorzystujących
go bezpośrednio.
Linus tradycyjnie podejmuje decyzje projektowe, które, zanim zostaną należycie zro-
ORT
Michał Piotrowski napisał mały skrypt,
ułatwiający użytkownikom tworzenie raportów o błędach. Nazwał go ORT – jest to
skrót od „Oops Reporting Tool”. ORT gromadzi różne dane dotyczące uruchomionego systemu, w tym informacje o błędach
(oops), i wysyła je na listę dyskusyjną li-
zumiane, spotykają się z głośnym sprzeciwem
wielu osób, potem zaś zyskują wielkie uznanie i stają się powodem do dumy. Najbardziej
spektakularnym przykładem ostatnich tygodni było wprowadzenie znaczników. Git
umożliwia nadawanie kolejnym wersjom repozytorium znaczników (tag), np. 2.6.12. Łatwiej odwoływać się do takich oznaczeń, niż
do wartości kluczy SHA1; łatwiej także zapamiętać nazwę znacznika i używać jej. Jest to
standardowa cecha systemów kontroli wersji,
w przypadku gita jednak znaczniki mają charakter prywatny. Osoba A może dodawać do
repozytorium wszelkie rodzaje znaczników,
a jeśli osoba B sklonuje to repozytorium, żadne znaczniki nie zostaną skopiowane, chyba
że osoba A przekaże osobie B odpowiednie
dotyczące ich informacje.
Rozwiązanie to ma wielu przeciwników,
oznacza bowiem utratę części historii danego repozytorium: repozytorium osoby B nie
jest już dokładnym klonem repozytorium
osoby A. Narusza to ogólną zasadę kontroli
wersji, nakazującą zachowywanie pełnej historii projektu. Linus jednak argumentuje
następująco: w rozproszonym środowisku
programistycznym domyślna propagacja
znaczników między repozytoriami oznaczałaby, że wszelkie znaczniki utworzone przez
dowolnego z programistów przenikałyby
wówczas do głównego jądra – znajdowałaby
się w nim ogromna liczba znaczników, całkowicie bezużytecznych dla każdego poza
ich autorem.
nux-kernel lub do opiekuna określonej części jądra.
Michał napisał to narzędzie, ponieważ wielu osobom brakuje czasu, cierpliwości lub
wiedzy niezbędnych do samodzielnego stworzenia poprawnego raportu o błędzie. W raportach wysyłanych na listę linux-kernel
o wiele za często brakuje wystarczających informacji o sprzęcie lub oprogramowaniu albo
nawet wersji jądra, której dotyczy dany błąd.
ORT został ciepło przyjęty przez wielu
twórców jądra; niektórzy proponowali nawet,
aby włączyć go do głównego drzewa. Pojawiło
się także parę głosów krytyki – najpoważniejsze z nich dotyczyły konieczności uruchamiania ORT-a z prawami roota. Wygląda jednak
na to, że te techniczne problemy zostaną
wkrótce rozwiązane i nie staną się żadną poważną przeszkodą.
TRZYMAMY KCIUKI ZA JOHNA HALLA
Na zakończenie wiadomości w tym miesiącu chcę dołączyć do wielu innych, życząc Johnowi Hallowi, autorowi książki
„Programming Linux Games” (nie mylić
z Jonem „Maddogiem” Hallem, innym
znanym autorem Linuksa) całkowitego
wyleczenia raka. U Johna zdiagnozowano
niedawno – po zaniedbaniu badania podejrzanego pieprzyka na ramieniu – czerniaka skóry. Pod adresem http://overcode.yak.net/3 pisze on bloga o walce z chorobą i prosi odwiedzających o wpłaty na
rzecz American Cancer Society. W blogu
znajduje się odnośnik do strony służącej
do przekazywania darowizn.
Kernel Traffic
Jeżeli regularnie czytasz ten dział, zachęcamy do odwiedzenia serwisu Kernel Traffic, gdzie przeczytać można więcej wiadomości dotyczących jądra. Stronę otwiera wprowadzenie autorstwa Zacka:
Kernel Traffic to grupa biuletynów informacyjnych, ale także jeden szczególny biuletyn, podsumowujący dyskusje na liście linux-kernel, głównej liście dyskusyjnej twórców jądra Linuksa. Linus Torvalds, Alan Cox i inni znakomici programiści wymieniają tam łaty, spierają się na temat szczegółów implementacji, omawiają najnowsze wydarzenia i po prostu tworzą historię.
Ze względu na ogromny ruch na liście (czasem do 3000 wiadomości tygodniowo) i wysoce techniczny charakter niektórych dyskusji, nie da się omówić wszystkich poruszanych zagadnień ani nawet streścić najbardziej interesujących wątków (a gdyby było to możliwe, czytanie takiej informacji
trwałoby niemal tyle, co czytanie samej listy). Jeżeli chcesz być na bieżąco z rozwojem Linuksa, nic
nie zastąpi czytania wiadomości wysyłanych linux-kernel.
Nazywam się Zack Brown. Zająłem się Linuksem w 1994 r., kiedy miałem ostatecznie dość
DOS-a. Od tego czasu z przyjemnością obserwuję, jak Linux staje się nie tylko świetnym systemem, ale również tematem ballad i legend.
WWW.LINUX-MAGAZINE.PL
NUMER 20 PAŹDZIERNIK 2005
13