Kernel Traffic #176 For 2002/07/22

To wydanie Kernel Traffic jest dedykowane niestrudzonym chłopakom z San Mateo County Mosquito Abatement District, bez których Dolina Krzemowa (zamieszkana przez wielu deweloperów jądra) zostałaby opanowana przez moskity, kleszcze i innych roznosicieli chorób takich jak: malaria, żółta febra, wirus hanta oraz dżuma. Zapomnij o wypadku autobusowym. Co, jeżeli Linus zaraziłby się dżumą?!?!?!

Tak jak faceci w czerni, agenci MAD są rzadko widziani i pamiętani. Nikt, kto znajduje się pod ich opieką nie mówi, ,,chłopaki, świetnie było spać całą noc i nie zostać zjedzonym przez moskity'', głównie dlatego, że nie ma w okolicy moskitów, na które możnaby narzekać. Ale Kalifornia zawsze była rajem dla moskitów, takich w które byś nawet nie uwierzył. Mówię o tych wielkich, które nie przestaną kąsać dopóki nie będziesz martwy!

Ci goście mają najlepszą pracę na świecie (co ostatnio odkryłem)! Po pierwsze latają poduszkowcami, co już samo w sobie jest warte odnotowania. Powodem, dla którego ich używają, są wielkie siedliska moskitów na podmokłych terenach, na które nie da się dotrzeć ani samochodem, ani łódką, a czasami nawet helikopterem (mam cichą nadzieję, że to czytają i kiedyś podarują mi taki poduszkowiec).

Używają także ubrań zagrożenia biologicznego 3-go stopnia, które co prawda nie zakrywają użytkowników całkowicie, jednakże są bardzo stylowe. Są im potrzebne, ponieważ, wierzcie lub nie, ale dżuma ciągle żyje, trzymana w szachu dzięki niestrudzonym wysiłkom tych oddanych nam awanturników.

To wydanie jest na ich cześć. Oni są niesamowici. Czapki z głów przed nimi!

There were 450 different contributors. 246 posted more than once. 158 posted last week too.

Jochen Suckfuell zaraportował, że w jądrach z serii 2.4 /proc/partitions zawiera niewłaściwe parametry we/wy. Powiedział, że zwracane wartości są albo zbyt wysokie, albo zbyt niskie. Spytał też, czy ktoś już pracuje nad łatką. Adrian Bunk odpowiedział, że drzewo Marcelo Tossattiego zawiera łatkę która usuwa całą funkcjonalność. Bill Davidsen wzburzył się,

Czy to jest nowy styl Linuksa? Usuwanie modułów jest trudne, POZBYĆ SIĘ TEJ WŁAŚCIWOŚCI! Statystyki w /proc/partitions nie zawsze są prawdziwe, POZBYĆ SIĘ TEJ WŁAŚCIWOŚCI!

Obsługa IDE w 2.5 sięgnęła dna. Czy to jest następne w kolejce?

Do rzeczy: ze znajdujących się tam statystyk korzysta wiele, szeroko używanych dystrybucji i jest to uważane za stabilną funkcjonalność. Czy jest to powód do niedodawania nowych? Czy w ten sposób można umotywować usunięcie tej właściwości? Jest to jedna z tych użytecznych rzeczy od których zależy, czy jakakolwiek partycje są na tyle zapełnione, by przenieść je na inne urządzenia. Tak, wiem, że są inne, bardziej skomplikowane sposoby do odczytania tych wartości. A dlaczego jest to pożądane? Dlaczego nie naprawić tej właściwości (Nie zgadzam się z opinią, że wszystko to jest w większości przypadków odległe)

Andries Brouwer stwierdził, że /proc/partitions tak naprawdę nigdy nie znajdowało się w oficjalnych jądrach. Powiedział: "Nie ma tego w 2.4.18 i wygląda na to, że nie znajdzie się w 2.4.19. Znajduje się za to w niektórych drzewach jądra, ale jest ,,brzydkie'' i powoduje różne problemy." Ktoś inny dodał, że ta funkcjonalność, tak naprawdę, nigdy nie została usunięta, a jedynie przeniesiona do /proc/diskstat. Dyskusja przerodziła się w poszukiwanie błędów, by następnie się zakończyć.

Jens Axboe ogłosił: "Przeniosłem rdzeń IDE z 2.4 (no, dokładniej to z 2.4.19-pre10-ac2) do 2.5.25." Wyjaśnił:

Dlaczego to zrobiłem? Cóż, potrzebowałem stabilnego IDE 2.5 do testów, a było/jest jasne, że 2.5 jeszcze nie jest w takim stanie. Będę utrzymywał tę łatę, dopóki nie będe przekonany, że IDE w 2.5 jest na tyle stabilne (w kodzie), że mogę zacząć spędzać czas nad nim. Zatem czas życia łaty zależy głównie od tego. Znam też inne osoby, które mogłyby potestować 2.5 nie martwiąc się tak bardzo o bieżący stan rdzenia IDE. Ten zestaw łat może być użyteczny również dla nich.

Dodatkowo kilka uwag, dlaczego tego _nie_ zrobiłem. Nie zrobiłem tego, bo uważam, że Marcin jest palantem, czy że IDE z 2.5 przepadło na zawsze. Nie zrobiłem tego, bo Andre wykręcił mi ramię. Nie zrobiłem tego, bo miałem jakiś ukryty plan.

Łatka u mnie działa. Wywaliłem ide-tape i ide-floppy (szczerze mówiąc, to nie sądzę, aby ich aktualizacja warta była zachodu), ale oprócz nich, sądzę, że jest cała funkcjonalność 2.4. Nie działa PIO multi count dla wielostronnicowych bio, jeśli chcecie tego używać, powinniście zmienić MPAGE_BIO_MAX_SIZE, jak to napisano w fs/mpage.c. Poprawię to w następnej iteracji.

Wiele osób nie posiadało się ze szczęścia. Ktoś zgłosił problem z kompilacją w niektórych konfiguracjach, a Jens szybko podesłał tymczasowe rozwiązanie obiecując lepsze w następnej wersji.

Erik Andersen wykrzyknął widząc tę łatę: "Wspaniale! Do tej pory 2.5.x było dla mnie zbyt przerażające. Ta łatka daje mi wystarczający margines bezpieczeństwa i mam zamiar teraz je wypróbować. Sądzę, że podobnie postąpi również wiele innych osób. 2.5.x stało się o wiele bardziej dostępne. Dzięki!" Gdzie indziej Miles Lane zauważył: "Dzięki Jens. To dość frustrujące, gdy się myśli, jak bardzo niestabilność IDE wstrzymała rozwój innych funkcjonalności w niestabilnym jądrze. Ciepłe przyjęcie Twojej łatki mówi samo za siebie."

Anton Altaparmakov był również podekscytowany widząc efekty pracy Jensa i spytał: "Widzę, że łatki są wygenerowane przez bitkeepera. Czy jest możliwość, abyś udostępnił repozytorium z łatkami? (na przykład na bkbits?) Dla nas, użytkowników bitkeepera, byłoby znacznie łatwiej po prostu wyciągnąć tę łatkę z Twojego repozytorium... Zwłaszcza, gdy będziesz aktualizował łatki..." Jens powiedział, że oczywiście, a inne osoby również stwierdziły, że będą zadowoleni widząc dostępne łatki. W pewnym momencie Jens ostrzegł: "Dodam może, że testowałem to na razie tylko na x86, na innych architekturach to powinno ,,po prostu działać'' po kilku zmianach w include/asm/ide.h (popatrzcie na zmiany w 15_24-misc-bits-1)." Nieco później podał odnośnik do drzewa BitKeepera, z którego można wyciągnąć łatki.

Ehmm. Mieliśmy ,,starą obsługę IDE'' od ,,wieków''. Mamy dwa sterowniki aic7xxx, dwa sterowniki rtl8139, dwa lub więcej sterowników ncr53c8xx.

Dlaczego zatem w przypadku IDE, ,,nowy sterownik IDE'' nie został wydzielony i zaimplementowany pod nową ,,nazwą'', tak aby ci, którzy pracują nad innymi rzeczami, mogli wybrać ,,stary działający'' sterownik, podczas gdy inni, chcący testować nowy kod, mogliby to robić?

A Jens odparł: "To naprawdę dobre pytanie, patrząc wstecz, MSZ widać, że tak powinno się stać."

Ja bym po prostu zrobił

vi fs/dcache.c -c '/|= DCACHE_R/d|/nr_un/pu|<|x'

i byłoby po wszystkim. Linus?

Linus Torvalds odpowiedział: "Zrobione. Na przyszłość jednak - proszę, niech nikt nie próbuje przysyłać łatek w postaci skryptów vi. Tak, jest to męskie, ale spójrzmy prawdzie w oczy - to jak skoki bungee z liną przywiazaną do Twoich klejnotów."

Ktoś zapytał, czy zostały wykonane jakieś testy mające na celu pokazanie, które z dostępnych jąder jest najbardziej stabilne. Kilka osób napisało, że nie ma naprawdę sposobu na przetestowanie takich rzeczy, ale Paul Larson podał odnośnik do Linux Test Project. Bill Davidsen zarekomendował używanie łatek Alana Coxa, jeśli wymagane jest SMP przy dużych obciążeniach; Joe Sloan polecił drzewo Andrei Arcangeli jako, że jet ono bardzo stabilne. Tomas Szepe napisał, że 2.4.19-pre10-ac2 działa mu od 36 dni, a 2.4.19-pre10 od 38 dni. Steven Cole zauważył: "Nawet z wczesnym jądrem 2.4.x można mieć dobre wyniki. Sądzę, że to naprawdę zależy od obciążenia. " A Kelsey Hudson odpowiedział: "rzeczywiście -- mam maszynkę umieszczoną u mojego dostawcy Internetu, na której działa 2.4.2 na płycie abit bp6, dwóch celeronach 366MHz, która nie wyłożyła się przez prawie 300 dni. Wydaje mi się, że najlepszy wynik to było 284 dni, albo coś równie niewiarygodnego; to robi wrażenie ze względu na tak starą wersję jądra jak i na nieustannie psujący się sprzęt. isp od tamtego czasu przestał funkcjonować ze względu na problemy finansowe i to jest jedyny powód dla którego zatrzymano tę maszynę, w przeciwnym razie jestem pewien, że ciągle by działała."

Muli Ben-Yehuda zasugerował, by kompilować jądro z włączoną opcją -Werror, aby ostrzeżenia kompilatora nie znikały z ekranu niezauważone. Kilku ludzi zaproponowało zamiast włączenia -Werror, przekierowanie wyjścia kompilatora do pliku i późniejszą jego analizę, ale Alan Cox zauważył: " Dodanie -Werror nie pomoże zbytnio, ponieważ gcc produkuje zbyt dużo bezsensownych ostrzeżeń podczas kompilacji." Linus Torvalds powiedział:

Szczególnie _niektóre_ wersje gcc.

Próbowaliśmy tego przedtem, ale istnieją wersje gcc, posiadające niektóre ostrzeżenia domyślnie włączone, co jest nie do zaakceptowania, ponieważ nie można się ich pozbyć w żaden rozsądny sposób (np. wydaje mi się, że co najmniej kilka snapshotów miało włączoną rejestrację ostrzeżeń, która powodowała naprawdę głupie ostrzeżenia, jednak mniej ohydne niż sposoby ich pozbycia się).

Prawdę mówiąc, nie sądzę by -Werror było takie złe. To może spowodować, że będziemy mieli mniej nowych sterowników powodujących niepotrzebne ostrzeżenia kompilatora.

Na liście zapytano, czy praca nad drzewem 2.0 jądra zostanie zaprzestana po uwolnieniu 2.6. Autor listu myślał, że jest to dobry pomysł, ponieważ to spowodowałoby napływ deweloperów starszych wersji jądra do pracy nad nowszym oprogramowaniem. Wielu ludzi nie zgodziło się z tą opinią. Końcowy konsensus oparł się na stwierdzeniu, że jeżeli ktoś używa 2.0, to powinien być zdolny do poprawienia błędów, które mu przeszkadzają. Alan Cox wyraził to słowami:

Dlaczego tak się tym przejmujesz? 2.0 bez problemu może kontynuować powolną i ostrożną drogę naprawiania krytycznych błędów dopóki ktoś będzie chciał to robić. Jest wiele komputerów z 2.0, które pracują jako routery, serwery drukowania, stacje do wdzwaniania się i prawdopodobnie jedyną możliwością przejścia na 2.4 jest awaria obecnego sprzętu.

Nie wiem co wynika z doświadczenia Davida Weinhalla, ale wiem, że zrobił o wiele więcej tropiąc błędy wysłane mu w bug-reports niż robiłem to ja z 2.2, ale moje doświadczenie mówi, że utrzymywanie bardzo stabilnego jądra, takiego jak 2.2 nie zajmuje już teraz zbyt wiele mojej pracy. Głównie zawiera się w wysyłaniu e-maili mówiących ,,nie''.

Nakład sił potrzebnych do opieki nad 2.0 nie jest zbyt duży. Zaimplementowałem kilka poprawek, które zostały mi wysłane i wyglądały na sensowne, odrzuciłem resztę (chociaż ostatnio większość wydaje się sensowna) i spróbowałem przenieść kilka, nadających się do tego celu, poprawek z 2.2/2.4. Nie dodaję żadnych nowych sterowników urządzeń (jak również ich nie tworzę) oraz nowych funkcjonalności.

Oprócz mnie istnieje kilka osób (pięć, nie więcej), które regularnie wysyłają mi raporty o ich sukcesach/porażkach/odczuciach związanych z najnowszymi wydaniami 2.0 oraz przypominają mi o zwiększeniu numeru podwersji (nie jestem lepszy w tej kwestii od Alana...)

Nakład pracy poświęcony nowszym wersjom 2.0 nie zmieni się, szczególnie teraz, gdy polubiłem tę robotę. Nie zostawię 2.0, chyba że kiedyś w przyszłości zostanie mi zaoferowana opieka nad 2.2 lub 2.4.

Przypominam, że ciągle istnieją ludzie, którzy używają 2.0 i nie zamierzają zmienić tego stanu w ciągu kilku najbliższych lat, po prostu dlatego, że ich sprzęt/oprogramowanie współpracuje z 2.0 oraz dlatego, że mają doskonale udokumentowane problemy związane z tą współpracą. Instalacja nowej wersji jądra oznacza konieczność wykonania tej pracy jeszcze raz. Najbardziej prawdopodobnym wydaje się aktualizacja raczej do wersji 2.2, niż do 2.4, ponieważ 2.4 ciągle otrzymuje nowe funkcjonalności i doświadcza zmian w API, czyli coś, na co zazwyczaj patrzy się krzywo z perspektywy administrowanego środowiska.

Zamierzam wkrótce opublikować 2.0.40. Ponieważ 40 jest ładną, okrągłą liczbą, a 42 nawet ładniejszą, by na niej zatrzymać, to prawdopodobnie będzie to koniec drogi. Jednakże ten koniec znajduje się gdzieś w dalszej przyszłości.

Guillaume Boissiere podesłał podsumowanie prac nad jądrem i zauważył: "Ponieważ zbliża się dzień zamrożenia kodu, to jest oczywiste, że wiele z tych projektów nie zostanie włączonych w ciągu najbliższych 3 miesięcy. Co byście chcieli żebym zrobił? Zatrzymał je tu po prostu jako odnośniki, zaznaczył jako elementy na po zamrożeniu, czy po prostu usunął?" Randy Dunlap zwrócił uwagę, że zamrożenie zaplanowano na 31 października, czyli za więcej niż trzy miesiące. Rik van Riel zaproponował zaznaczenie projektów o dłuższym czasie realizacji jako projekty ,,po zamrożeniu'', a nie usuwać, bo inaczej ludzie o nich zapomną. Dave Jones odparł: "W rzeczy samej. Być może dobrym pomysłem jest wzięcie tego, co zacząłem robić, a co można zobaczyć pod adresem: http://www.codemonkey.org.uk/Linux-2.5.html i połączenie tych dwóch. Guillaume, jeśli masz czas, to może poprowadzisz te dwie rzeczy, bo ostatnio, między hakowaniem a włączaniem łat, jestem dość zajęty, więc uaktualnienia tego pliku stają się mniej systematyczne." Guillaume odpowiedział:

Chciałbym móc więcej pomagać społeczności, a w szczególności Tobie, Dave, w chwili w której zbliża się zamrożenie w celu ogłoszenia 2.6 i śledzenie różnych rzeczy, ale jeśli jakaś firma Linuksowa mnie nie zasponsoruje, to nie będę mógł poświęcić temu więcej czasu niż do tej pory.

Skuteczne zajmowanie się śledzeniem gazyliona rzeczy i dręczenie ludzi o łaty jest po prostu niewiarygodnie czasochłonne.

Josh Litherland zapytał, czy z obecnym sterownikiem klawiatury może na swoim laptopie używać klawiatury PS/2 i klawiatury numerycznej na USB. Greg K-H napisał, że to powinno dobrze działać, ale Josh powiedział, że przy 2.4.18, nie dostawał zdarzeń z klawiaturki USB. Załadował sterownik evdev i potwierdził, że urządzenie zostało wykryte, ale nie docierały żadne zdarzenia. Brad Hards odpowiedział:

evdev jest po stronie trybu użytkownika w input core (a USB jest po drugiej stronie). Jeśli evdev zgłasza zdarzenia (a ty je możesz zdekodować, jeśli Cię to interesuje, używając narzędzi dostępnych w CVS-ie linuxconsole), to najprowdopodobniej z USB i input core jest wszystko w porządku.

Oczywistym błędem może być niewkompilowanie sterownika klawiatury w warstwie wejścia (albo nie załadowanie modułu, coś takiego).

Jeśli to na pewno nie jest źle (to znaczy lsmod pokazuje moduł, albo normalna klawiatura USB działa, a tylko klawiaturka numeryczna nie), to być może potrzebne są deskryptory HID. Najłatwiej chyba można je zdobyć z evdev używając narzędzia evtest z CVS-a linuxconsole.

Josh odpowiedział, że Brad trafił w sedno sprawy. Po skompilowaniu i załadowaniu sterownika klawiatury w warstwie wejścia, klawiatura i klawiaturka numeryczna działają razem.


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

1.	4 lip 2002 - 12 lip 2002	(12 posts)	Stan śledzenia dyskowych statystyk we/wy
2.	9 lip 2002 - 11 lip 2002	(26 posts)	Przepisywanie IDE w 2.5 przeszkadza innym deweloperom
3.	12 lip 2002 - 15 lip 2002	(18 posts)	Nowe konkurencje sportowe w świecie Linuksa - film o jedenastej
4.	12 lip 2002 - 15 lip 2002	(15 posts)	W poszukiwaniu stabilnych jąder
5.	13 lip 2002 - 16 lip 2002	(13 posts)	Aktywacja Ostrzeżeń Kompilatora
6.	13 lip 2002 - 15 lip 2002	(17 posts)	Status jądra 2.0
7.	16 lip 2002 - 17 lip 2002	(8 posts)	Stan opisu stanu
8.	18 lip 2002	(8 posts)	Jednoczesne używanie wielu urządzeń klawiatur

Kernel Traffic #176 For 2002/07/22

By Zack Brown

Translated By: Maja Królikowska , Paweł Kot , Robert Święcki and Tomasz Torcz