Kernel Traffic #167 For 2002/05/20

There were 416 different contributors. 185 posted more than once. 145 posted last week too.

Dan Kegel zgłosił, że khttpd powoduje oops na jego Power PC i nie jest w stanie serwować żadnych stron, gdy próbował użyć tego na x86. Anton Blanchard spytał: "Istnieje jakiś konkretny powód, dla którego nie używasz tuksa? Został porządnie przetestowany na ppc64 i te same łaty powinny zadziałać na ppc32." Dan odparł: "To super sugestia. Wygląda na to, że khttpd już się nie nadaje do produkcyjnego użycia (o ile kiedykolwiek się nadawał), a tux się nadaje." Ale Ken Brownfield odrzekł: "khttpd jak najbardziej nadaje się do produkcyjnego użycia na IA32 i tak jest od czasów 2.4.0-test1. Z drugiej strony TUX2 nie nadaje się do tego, ponieważ przy dużych obciążeniach wpada w pętle powodujące 99% zużycie procesora. Być może nie będziesz miał takich obciążeń, aby spowodować takie zachowanie TUKSA2. TUX1 się tak nie zachowuje." Jednak Andon odparł: "Tux2 działa u mnie stabilnie nawet przy bardzo dużych testach. Ingo był w stanie naprawić wszystkie błędy, których mi się nie udało naprawić -- szczegółowy raport ze zgłoszeniem błędu byłby mile widziany." Natomiast Dan zauważył, że khttpd zaczyna oopsować jeśli próbował włączać i wyłączać go w pętli.

Gdzie indziej w wątku khttpd śmierdzi? Dan powiedział "Wygląda na to, że nadeszła pora na naprawienie khttpd lub wyrzucenie go z jądra. W której wersji jądra khttpd był ostatnio stabilny (jeśli w ogóle)?" David S. Miller odpowiedział:

Mamy zamiar go wyrzucić z jądra.

Jedynym pytaniem jest, czy zastąpić go TUKSEM czy nie. Jest wiele niepodważalnych argumentów, że bardzo zbliżoną wydajność można osiągnąć w przestrzeni użytkownika.

Myślę jednak, że decyzja o TUKSIE nie jest związana z usuwaniem khttpd.

Dan odparł: "Prawda. Jeśli khttpd zostałby usunięty z 2.4.17 miałbym kilka tygodni ostrzeżenia, że khttpd jest niestabilne; zamiast tego dowiedziałem się o tym, dopiero, gdy ktoś inny przeprowadził testy i miałem za mało czasu, aby to poprawić. Usuń to w 2.4.19-pre9. Marcelo, usuń tego śmiecia asap... Nadszedł czas na khttpd w oddzielnej łacie."

Zaczęły krążyć różne łaty; różne osoby zaczęły oponować mówiąc, że od jakiegoś czasu używają khttpd bez problemów i będzie im przykro jeśli zniknie.

Pytanie, czy Tux powinien zostać włączony do jądra pozostało bez odpowiedzi, chociaż zostało wskazane, że Red Hat dołącza go do swoich jąder. Andrea Arcangeli spytał dlaczego, skoro Red Hat już to zrobił, włączenie go do jądra stanowi taki problem, a Alan Cox wyjaśnił: "Celem Red Hata jest udostępnienie przetestowanej dystrybucji o niebywale wysokiej jakości. Jest kilka rzeczy, których TuX wymaga do stabilności i wysokiej jakości, które Linus odrzucił, ponieważ zanieczyszczają kod takich rzeczy jak dcache, szczegółami istotnymi jedynie dla Tuksa."

Clifford White spytał, czy pojedynczy proces może użyć ponad 3G RAM. Luigie Genoni powiedział, że 3.6G to maksimum. Robert Love także powiedział: "Możesz dostać do 3.5GB, cokolwiek więcej staje się naprawdę ciężkie i niezbyt ładne. Możesz mieć jedynie 3.5/0.5 na nie-PAE -- PAE wymaga, aby segmenty były wyrównane do granicy 1GB."

W trakcie dyskusji Tomas Szepe zapytał, co się stało z CML2. Powiedział: "Nie widziałem żadnych zmian od mniej więcej lutego i również prawie na pewno nie natrafiłem na post ESR-a przez dość długi czas. " Dave Jones odpowiedział: "Wyglądało tak, że w opinii większości miało to za dużo bajerów, podczas gdy jednocześnie brakowało trochę bardziej podstawowej funkcjonalności wymaganej przez tych, którzy mogliby używać tego codziennie, na korzyść lukru dla użytkowników, którzy kompilują jądro raz na wydanie." Ktoś inny zaznaczył, również w odpowiedzi do Tomasa, że Eric S. Raymond został ,,wykopany'' z listy; co autor postu uważał za nie w porządku, biorąc pod uwagę, ile Eric wniósł do projektu. Sean Hunter odpowiedział:

Być może to będzie lekcją dla samookreślającego się ,,Hakera systemów społecznych'', że jest powód tego, że ma dwoje uszu i tylko jedne usta.

Jako haker potrzebował otrzymywać poparcie innych, aby jego praca została uznana i włączona. Nie słuchał rad i krytyki od tych, którzy wiedzą znacznie lepiej niż on, a jego praca nie była taka cudowna żeby ludzie byli gotowi zaakceptować ją bez zmian.

Nie był gotowy do wprowadzenia zmian, których chcieli inni, więc zabrał zabawki i odszedł obrażony.

Jednak Andrew Rodland zgodził się z poprzednim bezimiennym autorem postu. Powiedział: "Przeprowadziłem mnóstwo testów i napisałem trochę podstawowego kodu CML2 i myślę, że CML2 rowiązywał wiele istniejących problemów i że się ciągle poprawiał. Jasne, miał parę zabawnych problemów, ale naprawdę nie widzę tych wszystkich z którymi ludzie mieli do czynienia. Nawet autoconfig miał tendencje do robienia tej Właściwej Rzeczy. Myślę, że to było już prawie gotowe, aby ktoś zaczął to dokładnie testować i używać, gdy nagle wszyscy to zarzucili... A teraz nikt nie chce tego używać, gdyż oczywiście łatki nie współgrają z tym ładnie, i itd... Bardzo to smutne. "

Larry McVoy zgłosił: "mamy problem w jednym z drzew Linusa, który rozpoczął się propagować. Potrzebuję Waszej pomocy do wyśledzenia go i naprawienia. Uruchomcie, proszę, następujący skrypt na Waszych drzewach BK z Linuksem i skontaktujcie się ze mną, jeśli skrypt Was o to poprosi." Eli Carter spytał, cóż to za problem, a Larry odparł:

W skrócie chodzi o to, że dwoje ludzi uzyło Linusowych narzędzi importujących, nie ma tu błędu z jego strony, po prostu tak wyszło, spowodowało to jednak to, co nazywamy ,,duplikującymi się kluczami'' (podobnie jak duplikujące się i-węzły, bardzo podobnie), gdy naraz pojawiają się drzewa z importowanymi łatkami. Napisałem skrypt, który naprawia drzewa w razie wystąpienia takiego zjawiska, a skrypt ten nie zadziałał dobrze na drzewie Linusa, ale nie zauważylimy tego od razu. Zaczęło się to objawiać błędami operacji ,,pull'' i wtedy wszystko wyśledziliśmy.

Pisanie listu z długim wyjaśnieniem zabrałoby mi zbyt dużo czasu, mam problemy z nadgarstkiem, a takie wyjaśnienie wymagałoby napisania pracy ,,jak działa BK'', a to obecnie zbyt wiele dla mnie. Jeśli chcecie zrozumieć samo sedno, może mnie spytać używając głosu. Mówienie, przynajmniej narazie, nie powoduje bólu moich nadgarstków :)

Jest dostępna wersja 212 mojej łaty z devfs: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html Można tam znaleźć również FAQ do devfs.

Bezpośredni URL do łaty to:

ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.5/devfs-patch-current.gz

ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.5/devfs-patch-current.gz

UWAGA: jądro 2.5.1 i późniejsze wymagają devfsd-v1.3.19 lub późniejszych.

To jest do 2.5.14. Główne zmiany w tej wersji:

- Dodanie BKL do <devfs_open> ponieważ sterowniki cały czas tego potrzebują

Alexander Viro zauważył wyścig powodowany przez zmiany, a Richard po krótkim śledztwie to potwierdził. Powiedział:

W porządku, przejrzałem to. Jest tam rzeczywiście wyścig. Choć jest to bezpieczne z punktu widzenia ,,odładowywania'' modułów, to nie jest bezpieczne z punktu widzenia usuwania pozycji z katalogu. Rozważam kilka różnych sposobów rozwiązania tego (jeden jest prosty i oczywisty, inne będą nieco bardziej efektywne).

Pytanie: czy invalidate_device() i metody bdop check_media_change() i revalidate() mogą być wołane przy opuszczonej blokadzie?

Hmpf... To zależy od istoty blokady. Oczywiście spinlocki nijak się do tego mają (ponownie odczytujemy tablicę partycji tylko, jeśli dysk się zmienił i nie można zrobić tego nieblokująco ;-). Semafory mogą zadziałać, ale byłbym bardzo ostrożny z zakleszczeniami -- to samo ponowne odczytanie tablicy partycji może dodać lub usunąć pozycje devfs.

Czy mógłbyś opisać co próbujesz uzyskać w wywołaniach check_disc_changed()? Nie jestem w stanie tego wydedukować z kodu i jakiś komentarz by się przydał.

Są dwa przypadki, gdy chcemy ponownie odczytać partycję:

w lookup(), jeśli dana pozycja nie została znaleziona
w readdir().

Celem tego jest upewnienie się, że lista partycji jest uaktualniona (jeśli medium się zmieniło), gdy może na tym zależeć przestrzeni użytkownika. Bez tego kodu, jeśli medium się zmienia, i co za tym idzie zmieniają się również partycje, lista partycji, którą widzi devfs, jest już nieaktualna. W takim przypadku mogą się nie powieść dwie rzeczy (co najmniej):

ls na katalogu zgłasza, że już nie ma partycji
nie ma dostępu do nowej partycji, bo nowe pozycje nie zostały jeszcze zarejestrowane.

Kod zapobiega tym problemom.


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

1.	5 maj 2002 - 10 maj 2002	(35 posts)	khttpd opuszcza jądro; Tux przypuszczalnie wchodzi
2.	7 maj 2002 - 10 maj 2002	(20 posts)	Więcej niż 3G RAM dla procesu
3.	9 maj 2002	(18 posts)	Stan CML2 (Zaniechane)
4.	10 maj 2002	(4 posts)	Problemy z BitKeeperem
5.	10 maj 2002 - 12 maj 2002	(5 posts)	Polowanie na błędy w devfs

Kernel Traffic #167 For 2002/05/20

By Zack Brown

Translated By: Dariusz Grabowski , Maja Królikowska and Paweł Kot