Kernel Traffic #157 For 11 Mar 2002

To wydanie Kernel Traffic dedykuję mojej babci, Mildred Brown, 23 września 1908 - 5 marca 2002.

There were 504 different contributors. 249 posted more than once. 186 posted last week too.

Rusty Russell sądził, że seria 2.5 byłaby dobrym momentem na użycie jednej z dostępnych implementacji semaforów z przestrzeni użytkownika. Przesłał własną łatę, wyjaśniając:

Ta wersja używa mnożącego haszowania autorstwa wli, które ma następujące smakowite właściwości:

Interfejs to: open /dev/usem, pread, pwrite.
Nie jest wymagana inicjalizacja: po prostu mówisz jądru ,,to jest semafor: podnieś/opuść go''.
Brak zawartego w jądrze, specyficznego dla architektury kodu.
Blokowania w mmapach są stałe (nawet między restartami!).

Ingo Molnar miał wrażenie, że łata jest dobra, ale nie podobał mu się interfejs. Napisał: "/dev/usem jest takim ... ioctl()-owym podejściem." Zaproponował: "Dlaczego nie stworzyć nowych wołañ systemowych? Myślę, że te lekkie semafory zostaną ważną częścią Linuksa, zatem posiadanie własnych wołañ systemowych jest najbardziej poprawnym interfejsem." Wyjaśnił, że chodzi o coś pośród linii składających się z sys_sem_create(), sys_sem_destroy(), sys_sem_down(), i sys_sem_up(). A Linus Torvalds dodał: " Zgadzam się - nie lubię magicznych plików urzadzeñ o wiele bardziej niż jakiejkolwiek alternatywy." Rusty napisał, że zrobiłby implementację opartą o wołania systemowe: "i zobaczył, czy tak naprawdę mogę zmusić to do pokonanania blokowania fcntl w rozsądnych testach (to znaczy tdbtorture)."

On i Linus przez kilka chwil dyskutowali w te i wewte na temat implementacji, nie zgadzając się w dokładnej semantyce. W pewej chwili Linus napisał:

Osobiście preferowałbym raczej interfejs bardziej podobny do tego:

fd = sem_initialize();
mmap(fd, ...)
..
munmap(..)

który daje Ci uchwyt do semaforów.

Zauważ, że otrzymywanie deskryptora pliku jest całkiem użyteczne - oznacza to, że możesz przekazywać ten deskryptor na przykład przez gniazda uniksowe; pozwala to też na dzielenie semaforu pomiędzy niezwiązanymi procesami.

W ten sposób deskryptor pliku zachowuje się także jak ,,kotwica'' dla jakichkolwiek struktur danych jądra, które mogą (ale nie muszą) być wykorzystane przez implementację semaforów. Pomyślcie o tym jako o /dev/usem z bardziej bezpośrednim interfejsem.

Spraw też, żeby początkowy mmap() pracował tylko na ograniczonej liczbie stron, tak żeby ludzie nie zaczynali w ten sposób próbować alokować ton pamięci.

2. Współdzielenie zegara czasu rzeczywistego pomiędzy przestrzenią jądra a użytkownika

Jaroslav Kysela wysłał łatę pozwalającą jądru na użycie zegara RTC. Jak powiedział, mogłoby być to użyteczne dla sekwensera ALSA. Pavel Machek wytknął, że to zostawiłoby na lodzie takie architektury jak Sparc i Alpha, które nie mają RTC. Jaroslav odpowiedział, że domyślnym zachowaniem byłoby wykorzystanie istniejącego już w jądrze zegara, ale o ile RTC byłoby dostępne, możnaby go wykorzystać. Roman Zippel czuł, że RTC można wykorzystać bez modyfikacji jądra i pokazał sposób na zrobienie tego:

To, co robi ta łata może być zrobiona w przestrzeni użytkownika:

fd = open("/dev/rtc",...);
ioctl(alsafd, RTCFD, fd);

w sterowniku alsa możesz zrobić:

file = fget(fd);
...
if (file->f_op && file->f_op->ioctl)

file->f_op->ioctl(file->f_dentry->d_inode, file, cmd, arg);

...
fput(file);

Jaroslav powiedział, że sterownik będzie potrzebował także obsługi przerwania, ale Roman odrzekł, że to może być zrobione przez kolejkę zadañ. Nie było odpowiedzi.

Marcelo Tosatti ogłosił 2.4.18, ale chwilę później odkrył, że zapomniał włączyć do tej wersji zmian z 2.4.18-rc4. Powiedział, że naprawi to w 2.4.19-pre1, ale Daniel Quinlan zasugerował umieszczenie 2.4.19 z dodaną tylko tą łatą. Wskazał, że nic złego się nie stanie przez stworzenie jeszcze jednej wersji, ale Marcelo nie sądził, żeby był to wystarczająco ważny błąd, aby usprawiedliwić takie działanie. W międzyczasie Justin Piszcz popatrzył na 2.4.18 i stwierdził, że łata rc4 jest jednak zaaplikowana, ale Dave Jones odpowiedział: "Tylko jeden kawałek zniknął, nie całe rc4. Sprawdź diffa rc4-final z testing/incr/ i zaaplikuj z -R"

W innym miejscu Bruce Holzrichter zaproponował oznaczenie 2.4.18 koñcówką ,,-dontuse'' w miejscach, z których jest ściągane, ale Marcelo napisał: "Nie. Znacznik ,,-dontuse'' powinien być używany tylko w odniesieniu do jąder, które mogą spowodować szkody w jakikolwiek sposób. Łata, o której zapomniałem, psuje tylko statyczne aplikacje na _niektórych_ architekturach (nie na x86)." Dodał, że zmienił ChangeLog tak, aby zawierał: ,,Uaktualnienie: Poprawka SET_PERSONALITY z rc4 przez pomyłkę _nie_ została włączona w finalne 2.4.18''.

Bernd Eckenfels i Hilsen Harald zgodzili się z Danielem. Jak ujął to Bernd: "Nie rozumiem dlaczego problemem jest wypuszczenie w zamian 2.4.19." Chwilę potem Stephan von Krawczynski miał wrażenie, że Marcelo poświęca niewiele uwagi maszynom innym niż x86. Napisał: "Po prostu uważasz te architektury za mniej ważne. A przynajmniej nie aż tak ważne, aby wypuszczać na nie wersje, które mają tak mało błędów jak to tylko możliwe w danej chwili. Nie powinieneś tego robić, nie skupiaj się zbytnio na tym, co uważasz za ,,główny nurt''. Tak jak wcześniej napisano, mylić się jest rzeczą ludzką. Musisz tylko radzić sobie z takimi sytuacjami w inteligentny sposób i być świadomym tego, jaką dano ci władzę. W moim przekonaniu, najładniejszym rozwiązaniem byłoby wypuszczenie wersji 2.4.19. "

Rik van Riel napisał, że Stephan powinien sam wydać 2.4.19 jeśli tego chce. Powiedział: "Zbyt łatwo jest ludziom krytykować marcelo, nie zdając sobie sprawy z tego, jak wiele pracy wkłada on w 2.4." Stephen odparł: "Ten komentarz był bezsensowny. Jest grupa ludzi, którzy mogą _stworzyć_ jądro, ale tylko jedna osoba może je _wydać_. Nie ma potrzeby dyskutowania, czy jestem członkiem tej grupy, ale na pewno ani ja, ani ty nie jesteśmy _tym_ jedynym. Obaj nie możemy więc robić niczego więcej poza wyrażaniem naszych osobistych opinii na ten temat."

W innym miejscu, ktoś zasugerował, aby po prostu wystawić poprawioną wersję 2.4.18; Marcelo stwierdził, że wywołałoby to problemy z systemem mirrorowania serwerów FTP. David S. Miller zauważył: "Możemy uniknąć tego rodzaju bałaganu w przyszłości, jeśli wersje ,,-rc*'' rzeczywiście będą ,,kandydatami do wydania'', a nie ,,po prostu kolejnym diffem''. Tzn. będą robione jako łaty _i_ jako tarballe, wtedy wersja koñcowa może być po prostu utworzona przy użyciu komendy ,,cp''. Ten sposób pozwoli na łatwiejsze wyłapanie tego typu błędów w przyszłości." Ale Thomas Duffy zwrócił uwagę, że makefile w najwyższym katalogu i tak musiałby być zmieniony, aby odpowiadał on nowemu numerowi wersji. Wyrzucenie ,,-rc'' z kandydatów do wydania, napisał, spowodowałoby zamieszanie. Dodał: "Ostatnią rzeczą, którą bym chciał, to pracować z jądrem 2.4.18-rc3 i uname'm mówiącym mi, iż jest to 2.4.18." David odparł:

Uważam, że korzyści płynące z niespieprzenia prawdziwego wydania są większe niż ta niedogodność.

Tak na marginesie, to uważam również, że głupotą jest fakt, iż nie możemy po prostu zrobić ,,poprawek'', kiedy popełniony zostanie niewielki błąd, taki jak ten. W najgorszym wypadku możnaby wydać naprawdę szybką wersję ,,2.4.18a'', która zawierałaby te poprawki.

Osobiście, po prostu wystawiłbym poprawione pliki i powiedział ,,przepraszam, ale oryginalnej wersji nie obsiusiał święty pingwin, a tą tak'' i powiedziałbym ludziom żeby po prostu sobie radzili.

W innym miejscu, jeszcze więcej gości napisało, że wypuszczenie 2.4.19 byłoby właściwym rozwiązaniem.

Michael Cohen zebrał zestaw łat i wyczyścił je tak, by nakładały się dobrze na 2.4.19-pre1. Poza innymi rzeczami, załączył łatkę, która mogła zużyć wszystkie nieprzydzielone numery główne urządzeñ blokowych. Alan Cox napisał: "Jak to wcześniej przedyskutowano - to jest kiepski pomysł. Proszę, nie wracajmy już do niepoprawnych łat - to nie jest pomocne." Richard Gooch (autor łaty, o której była mowa) odpowiedział: "Nie, Alan. To *ty* uważasz, że to nie jest dobry pomysł. Nie każdy się z tobą zgadza. Moja łata jest bezpieczna: wykorzystuje bezpieczną funkcję alokacji numerów głównych, w ten sposób iż może być użyte >128 SD-ów. Wydaje się, że jesteś przeciwny tej łacie, bo ona oznacza, że nie możesz po prostu rozdawać numerów głównych, ignorując Linusowe przykazanie ,,żadnych nowych numerów głównych''." Alan odparł: "To przykazanie nie ma związku. Możesz żyć sobie w swojej małej wieży z kości słoniowej, jeśli cię to uszczęśliwia, ale wszyscy inni korzystają z polinusowego devices.txt, którym opiekuje się LANANA."

Christer Weinigel podesłał łatę, która " dodaje do jądra obsługę procesorów National Semiconductor z rodzin SC1200, SC2200 i SC3200. " Marcelo Tosatti odparł, że nie da się bezproblemowo nałożyć tej łaty na jego drzewo, prawdopodobnie ze względu na inne łaty, których Christer sobie używał. Christer przedstawił nową łatkę na ostatnią wersję pre.

Michael Cohen przysłał łatę na sterownik RivaFB w 2.4. Marcelo Tosatti odpisał, że powinien wysłać ją najpierw opiekunowi RivaFB. Jeff Garzik odpowiedział: " szczerze mówiąc, nie ma takiej osoby..... " Marcelo zauważył, że Ani Joshi był oficjalnym opiekunem, a Jeff odparł: "Ani najpierw zgłosił się na ochotnika na tę pozycję, a potem przez ponad rok ignorował wysyłane mu łaty. Kiedyś ja byłem opiekunem rivafb (popatrzcie kto napisał riva/fbdev.c...), potem zaczęło mi brakować czasu. Kiedy poszukiwałem nowego opiekuna, on zgłosił się do objęcia tej pozycji, ale żadne łaty nie nadchodziły..." Dodał: "Ferenc Bakonyi wykonał kawał dobrej roboty i moim zdaniem, jeśli dalej jest gdzieś w pobliżu, byłby dobrym kandydatem do opieki." Marcelo odparł, że otrzymywał i nakładał łaty dotyczące RivaFB, które wysyłał mu Ani, na co Jeff odpowiedział: "Super! Cieszę się, że powrócił." Koniec wątku.

Pete Zaitcev zauważył, że obsługa s390 została zepsuta w jądrach w okolicach 2.4.18. Podesłał poprawkę, a Martin Schwidefsky z IBM-a odpowiedział: "Łata, która została dodana do 2.4.18-pre* została stworzona dla 2.4.17-pre7 i to działało. Problem polega na tym, że nie wszystkie zmiany, które przesłałem Marcelo, zostały zaakceptowane. Jedną z łat była poprawka asm-offsets, która usuwała wszystkie na sztywno wpisane przesunięcia z entry.S. Zaakceptowano też inną łatę, która zmieniała strukturę wątków i spowodowała tę niespójność." Pete odparł: "Proszę, nie dawaj Marcelo z tym spokoju, szkoda, że nie zrobiłeś tego zanim wypuszczono 2.4.18."


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

1.	22 Feb 2002 - 4 Mar 2002	(47 posts)	Semafory w przestrzeni użytkownika w 2.5
2.	24 Feb 2002 - 28 Feb 2002	(6 posts)	Współdzielenie zegara czasu rzeczywistego pomiędzy przestrzenią jądra a użytkownika
3.	25 Feb 2002 - 28 Feb 2002	(54 posts)	Obsługiwanie błędów przy wydaniach
4.	25 Feb 2002 - 1 Mar 2002	(9 posts)	Stan wiarygodności 2.4 Linusa
5.	25 Feb 2002 - 3 Mar 2002	(5 posts)	Stan obsługi NatSemi SCx200
6.	25 Feb 2002 - 28 Feb 2002	(7 posts)	Stan opieki nad RivaFB
7.	4 Mar 2002 - 6 Mar 2002	(4 posts)	Obsługa s390 jest zepsuta w 2.4.18

Kernel Traffic #157 For 11 Mar 2002

By Zack Brown

Translated By: Jakub Jankowski , Maja Królikowska and Paweł Kot