Kernel Traffic #164 For 2002/04/29

Jakiś czas temu próbowałem umieścić odnośniki ze Spisu Treści każdego wydania do XML-owego źródła tego wydania, ale XML okazał się być za bardzo niezgodny ze sobą. Na szczęście wszystko zostało naprawione i powinniście ujrzeć działające odnośniki do źródeł każdego wydania (włącznie z tłumaczeniami) w XML-u. Ogromne podziękowania dla autorów i tłumaczy przeróżnych Traffików za pomoc w doprowadzeniu źródeł do zgodności.

Przy okazji, chciałbym zwrócić waszą uwagę na Consensus At Lawyerpoint, stronę stworzoną przez Electronic Frontier Foundation. Otóż wielkie korporacje medialne co miesiąc wydają miliony dolarów w celu wprowadzenia praw, które, oprócz innych rzeczy, uniemożliwią tworzenie wolnych sterowników do kart z tunerami cyfrowej telewizji. To bardzo skomplikowana sprawa, ale równocześnie bardzo ważne, aby ludzie dobrze zrozumieli, co się dzieje i walczyli. Więcej informacji znajdziecie w tym podsumowaniu, możecie też skontaktować się z Sethem Davidem Schoenem z EFF.

There were 345 different contributors. 171 posted more than once. 121 posted last week too.

Robin Johnson wysłał skrypt i napisał: " stworzyłem skrypt do tworzenia łatek pośrednich, takich jakie wcześniej były dostępne na bzimage.org. Napisałem go, aby różnym osobom łatwiej było tworzyć takie łatki pośrednie." Adrian Bunk podał odnośnik do patchutils Tim Waugha zawierających 'interdiff': "który tworzy pośrednie diffy między łatkami. Dodatkowo interdiff nie wymaga źródeł, dla których zostały stworzone łatki." Robin odpowiedział, że próbował interdiffa, ale nie otrzymał poprawnego wyjścia. Tim Waugh odpowiedział: "Wydaje mi się, że problemy Robina zostały rozwiązane w patchutils-0.2.12. (Wyjście było poprawne, ale zbyt długie)."

Greg KH wysłał kilka BitKeeperowych changesetów i ogłosił: "Te changesety dodają do jądra obsługę urządzeń USB. To kod firmy Lineo troszkę oczyszczony i wrzucony do drivers/usb/device/. Z upływem czasu, większość kodu wyemigruje do innych katalogów w obrębie usb, a rdzenie sterowników urządzeń i hosta USB połączą się. Ta wersja buduje się poprawnie i daje dobrą bazę do pracy." Podał także odnośnik do zwykłej łatki zawierającej te same zmiany. Greg dodał także: "Podziękowania dla Stuarta Lynne'a z Lineo za udostępnienie kodu i pracę nad włączeniem go do drzewa." A Stuart Lynne odpisał: "Podziękowania należą się Lineo za pracę z klientami w celu udostępnienia tego na zasadach GPL i dla Tima Birda za zezwolenie mi na stworzenie oficjalnej wersji, dzięki czemu ludzie nie muszą wykopywać tego ze źródeł jądra Zaurusa produkcji Sharpa."

Kilka godzin po pierwszym ogłoszeniu Greg wysłał poprawkę (i łatkę), która "usuwa kod dla arm sa1100 z ostatniej wersji, jako że powininien być używany sterownik USB z drzewa ARM, zamiast poprzedniej starej wersji. Popracuję z ludźmi od ARM nad włączeniem tego w ich drzewo." Linus Torvalds odpowiedział:

Ponieważ nie wziąłem jeszcze żadnych uaktualnień urządzeń usb, proponuję:

zrobienie archiwum BK całkowicie od początku bez popsutej serii (czyli w zasadzie ,,bk undo'')
wyjaśnienie mi czym jest ,,urządzenie usb'', jeśli nie jest normalnym urządzeniem USB? Czym się różni ,,usb/device/xxx'' od istniejących sterowników urządzeń USB?

Innymi słowy, proszę wyjaśnić _po co_ jest ten kod? Zwłaszcza, że jest oczywistym śmieciem po pierwszym pobieżnym przeczytaniu, i całkiem uczciwie mówię, że ten kod nie powinien nawet _zbliżyć_ się do jądra zanim nie przejdzie przez _gruntowne_ czyszczenie.

Nie ma co ukrywać, spójrz chociaż na totalne GÓWNO w usbd-debug.c, gdzie ktoś ponownie stworzył strcmp/strcpy/itd, tyle, że z głupimi nazwami i źle zaimplementowane.

Krótko mówiąc, odmawiam wciągnięcia tego świństwa. Ludzie którzy to napisali byli albo na prochach, niekompetentni albo po prostu szaleni. ,,Po prostu powiedz nie''.

Greg wyjaśnił: "To kod urządzenia klienckiego USB, nie hosta USB, który w tej chwili mamy. Jest używany przez urządzenia wbudowane działające pod kontrolą Linuksa" . Linus odpowiedział, że mógł zbyt pochopnie wykląć łatkę (której jak napisał, nie przeczytał w całości). Dodał:

Aaaa.. Ciemne światełko rozjaśnia się.

Bardziej sensowne (wg. mnie) byłoby nazwanie tego ,,usb/client'' zamiast ,,usb/device'', ale może po prostu nie zrozumiałem o co chodziło.

(zapytaj kiedyś Davema o mojego irracjonalnego hopla na punkcie nazewnictwa i jak to się czasami dzieje, że podoba mi się ten sam kod, tylko nazwany inaczej ;)

Greg odpowiedział: "My (lista linux-usb-devel) dyskutowaliśmy o różnych nazwach i staraliśmy się podążać za konwencją przyjętą w specyfikacji USB. Jednakże 99% programistów jądra nigdy nie przeczyta dokumentacji, 100% użytkowników także nie, a nazwa ,,urządzenie'' nie została poprawnie odczytana przez pierwszą osobę spoza grona twórców USB, która ją ujrzała. Zmiana nazwy na ,,klient'' jest o wiele bardziej sensowna :)" Linus odpowiedział:

Zauważ, że dla większości osób waga specyfikacji USB jest równa dokładnie 0%.

,,Urządzenia USB'' to dla większości ludzi rzeczy, które ty nazywasz ,,klientami''. Prawdziwy świat jest ważniejszy i linuksowa nazwa ,,Sterownik Urządzenia USB'' _nigdy_ nie powie, że ten sterownik zamienia komputer w urządzenie USB.

,,Sterownik urządzenia USB'' to sterownik myszy/skanera/czegokolwiek, tj. _drugiego_ końca, i tak po prostu jest. Twierdzenie czegoś innego jest mylące i głupie.

Ponieważ mówimy o drugim końcu sterownika ,,hosta'', nazwa ,,klient'' jest całkowicie uzasadniona - w świecie komputerów ,,klient'' to zawsze przeciwieństwo ,,gospodarza'' (,,hosta''), chociaż może tylko mi sie tak wydaje. Poza komputerami, ,,gość'' wydaje się poprawnym antonimem, ale to z kolei wydaje mi się dziwaczne (,,Sterownik Gościa USB''?).

Jakieś inne sugestie?

Kilkanaście osób zróciło uwage, że odejście od terminologii używanej w standardzie USB będzie daleko bardziej mylące dla osób pracujących nad kodem, jednakże nikt nie stwierdził, że dla kolesi nie-od-USB ta terminologia będzie miała jakikolwiek sens bez patrzenia w specyfikację.

W pewnym momencie Larry McVoy zaproponował: "A co z ,,celem'' (ang. ,,target'')? W świecie SCSI jasnym jest, że cel to urządzenie, a kiedy mówisz o kodzie który pracuje na komputerze i czyni go celem w sensie SCSI, każdy wie o co chodzi, prawda? Co więc z kodem, który czyni komputer celem USB? Nadaje się? To jedyne, co mi przyszło na myśl, gdy myślę o czymś podobnym. Czy USB używa już terminu ,,cel'' dla czegoś innego?" Linus odpowiedział:

Cóż, dla mnie brzmi to jasno, i ,,ma sens''.

Co jednak oczywiście nie rozwiązuje kwestii czystości nowego kodu. (modulo dokumentacja USB mówiąca, że ,,cel'' oznacza małą, kontrolowaną przez USB rybkę, motając wszystkich koderów USB).

Greg stwierdził, że 'cel' mu pasuje, a co do kwestii czystości: "Właśnie nad tym pracuję. Zabierze to trochę więcej czasu niż tylko zmiana nazwy katalogu i poprawki w dokumentacji :) "

Chris Abbey spytał: "Nie dalej jak w lutym ktoś pytał o obsługę kart Promise, Alan wspomniał, że prawdopobnie zostanie włączona w okolicach 2.4.19. Ciekaw jestem, jakiej obsługi ludzie się spodziewają? Tylko podstawowe IDE, czy też obsługa sprzętowego RAID-u? Robię się chory od uruchamiania stareńkiego jądra w celu wyciągnięcia danych z raidu, a jeszcze bardziej chory, z powodu twardych zwisów które zdarzają się tylko, gdy mam zainstalowany binarny moduł. (proszę, nie wszczynajcie znowu wojen o to, jak brudne są moduły binarne. Zdaję sobie z tego sprawę, ale żyję w prawdziwym świecie i mam mnóstwo danych na jednym z ich kontrolerów. :( )" Alan Cox spytał, co Chris miał na myśli mówiąc o sprzętowym RAID-zie. Napisał: "OIMW jedynymi ich kartami ze sprzętowym raidem są supetrak 100 i SX6000." Chris odpowiedział "FastTrak 100 TX2 ma sprzętowy raid (striping/mirror), mają nawet binarny sterownik (scsi/ft.o) który przedstawia macierz jako urządzenia scsi... to jest poziom funkcjonalności, który mam nadzieję zostanie włączony." Dodał: "Aktualnie 2.4.18 rozpoznaje kartę i daje czyściutki dostęp do dysków dzięki IDE. Niestety, to niewiele, dopóki ktoś nie spróbuje rozpracować ich sposobu alokacji na dyskach w raidzie ... zapewniam, że nie jest to trywialne. ;(" Arjan van de Ven i inni wskazali, że jest to programowy RAID, a nie sprzętowy. Chris zauważył: "Wiecie, poważnie wątpiłem, czy ten raid jest naprawdę sprzętowy, inaczej dlaczego nie chcieliby pokazać sterownika? ;)"

Następująca łatka implementuje znane z 2.5 wywołania systemowe afiniczności zadań w algorytmie szeregującym O(1) dla 2.4, który niedawno wysłałem. Możemy je teraz zaimplementować, bo scheduler O(1) w 2.4 ma już migration_thread. Wcześniejsze łatki dla 2.4 które zrobiłem, działały tylko na ,,standardowym'' algorytmie szeregującym.

Proszę o komentarze:

Blokowanie w tej łatce nie jest dobre. set_cpus_allowed nie jest atomowa i na pewno nie jest bezpiecznie trzymać blokadę wołając ją. Jednak przed wołaniem set_cpus_allowed potrzebujemy poprawnego odwołania do procesu i zapewnienia, że w międzyczasie nie wyślizgnie się spod nas.

Powiecie pewnie ,,eh, złap tasklist_lock'', ale nie możemy trzymać tej blokady w czasie set_cpus_allowed. W 2.5 rozwiązujemy ten problem przez podbicie licznika użyć task_struct poprzez get_task_struct - to daje nam pewność, że task_struck nigdzie nie zniknie póki nie zrobimy put_task_struct. Nie mamy takiego luksusu w 2.4...

Mike Kravetz rzucił okiem na łatkę i znalazł obszar, który chyba pozwala procesowi wyemigrować znienacka na inny CPU. Wydawało się, że nie ma niczego, co by powstrzymało taką migrację. Ingo Molnar wyjaśnił:

wątek migracji daje pewność, że migrujący proces *nie* będzie działał na tym konkretnym CPU. Jedynym zadaniem wątku migracji jest 'wypchnięcie' migrującego procesu z jego bieżącego CPU.

najpierw więc ustawiamy maskę cpus_allowed, potem, jeśli wątek działa na złym CPU, szeregujemy do wykonania wątek migracji (który ma najwyższy priorytet czasu rzeczywistego).

load_balance() przesuwający proces na inny CPU w zasadzie ułatwia tę robotę i nie sprawia problemów. Wypchnie proces tylko do dozwolonych kolejek do wykonania.

w ten sposób można zagwarantować, że po wywołaniu set_cpus_allowed wątek nie działa na złym CPU.

wywołanie ustawiające afiniczność, które dodaje łatka Roberta, wykorzystuje ten mechanizm, ale wątki jądra wywołują go również bezpośrednio. Np. w przypadku softirdq ważne jest, czy wątek działa na właściwym CPU po wywołaniu set_cpus_allowed(), czy też nie.

To wydało się Mike'owi sensowne, a Ingo dodał: " wszelkie dodatkowe oczy są mile widziane :) Jedynym delikatnym aspektem koncepcji migracji jest inicjalizacja (kiedy nie ma mechanizmu migracji, aby wymigrować pomocnicze wątki migracji ... paragraf-22), poza tym bieżąca implementacja migracji jest bardziej wszechstronna niż poprzednie podejścia. (mieliśmy już w algorytmie szeregującym O(1) paręnaście podejść, wszystkie były bardzo inwazyjne i ograniczone.)"

James Simmons ogłosił: "właśnie skończyłem wysyłać ostatnie duże zmiany, jakie chciałem posłać Linusowi w kwestii zmian w buforze ramki. Ponieważ nie mogę przetestować wszystkich możliwych konfiguracji sprzętowych, proszę wszystkich o sprawdzenie drzewa BK. Jak tylko dostanę pozytywne raporty, chciałbym połączyć je z drzewem BK Linusa. Dziekuję. " Podał odnośnik do swojego drzewa BitKeepera, ale Jes Sorensen wniósł zażalenie: "Jeśli chcesz aby ludzie sprawdzili łatkę, podawanie tylko adresu bitkeeperowego jest bez sensu! To jest dokładnie to, co spowodowało kiedyś długą kłotnię na linux-kernel. ;-(" James wysłał zwykłego diffa dla 2.5.9 i poprosił ludzi o przetestowanie.


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

1.	Wto, 16 kwi - Sob, 20 kwi	(5 posts)	Budowanie łatek pośrednich
2.	Wto, 16 kwi - 19 kwi 2002	(29 posts)	Obsługa lokalnych urządzeń (celów) USB
3.	Sob, 20 kwi - Wto, 23 kwi	(10 posts)	Dyskusja o obsłudze kart Promise w 2.4
4.	22 kwi 2002 - Wto, 23 kwi	(5 posts)	Afiniczność CPU z algorytmem szeregującym O(1) pod 2.4
5.	Pon, 22 kwi - Wto, 23 kwi	(3 posts)	Kod bufora ramki (framebuffera) używający BitKeepera

Kernel Traffic #164 For 2002/04/29

By Zack Brown

Translated By: Tomasz Torcz