Kernel Traffic #124 For 2 Jul 2001

Być może zauważyliście, że część artykułów w tym wydaniu zostało napisanych przez Adama Buchbindera, który przypuszczalnie będzie ze mną współpracował przy następnych numerach. Zainteresowani współpracą są proszeni o kontakt ze mną. Pisanie Kernel Traffic jest znaczącym przedsięwzięciem. Pomoc by się przydała.

There were 445 different contributors. 210 posted more than once. 154 posted last week too.

Tim Hockin spytał czy EEPRO/100 S będzie działać pod Linuksem, na co Kelledin Tane odpowiedział, że sterowniki udostępniane przez Intela są również w wersji dla Linuksa i to nawet na zasadach GPL. Jednak J. S. Peatfield zayważył:

Sterownik e100 Intela niby wspiera te karty (tzn. 100 S), ale tak naprawdę, to sterownik ten wiesza się przy dużym natężeniu pakietów UDP (przynajmniej u mnie z jądrem 2.2.19). Wygląda na to, że ten problem występuje tylko w wypadku nowych kart -- ze starszymi (i takimi jak 100VE) nie ma raczej kłopotów.

Intel pracuje nad usunięciem tych zwisów. Pierwsze podejrzenia padły na obciążenie związane z obliczaniem sum kontrolnych, ale wyłączenie tego nie pomogło. Wersja 1.66 jest dużo stabilniejsza niż 1.55a (1.55a zawieszała się po przetrawieniu jakichś 60-80MB ruchu w sieci). Cały czas czekam na nową wersję, żeby zobaczyć, czy sobie z tym poradzili.

Sterownik nie jest na GPL-u (nie wiem dlaczego) i nie umożliwia szyfrowania na kartach, które to udostępniają (a Intel nie wyraża chęci ujawnienia szczegółów specyfikacji, tak aby inni mogli napisać sterowniki obsługujące szyfrowanie).

Od dzisiaj, Paul Meckerras (paulus@samba.org) przejmuje obowiązki związane z prowadzeniem rozwoju jądra Linuksa w wersji na 32-bitowe procesory PPC i będzie również prowadził jądro Linux/PPC w wersji na 64-bitowe procerosy.

Stabilne i rozwojowe drzewa (2.2 i 2.4) przeniosą się z repozytorium ftp/rsync/BitKeeper w FSMLabs do CVS na vger.kernel.org. Dalsze zmiany powinny odnosić się do drzewa, które znajdziecie na kernel.org.

Paul podjął wątek: "Cort włożył niewyobrażalną ilość czasu i pracy z rozwijanie wersji Linuksa na PowerPC przez ostatnie 5 czy 6 lat i chciałem mu publicznie za to podziękować. Wiem, że nie było to zawsze proste, głównie ze względu na rozbieżności wśród osób pracujących nad Linux/PPC. Cort był zawsze tym, który znajdował kompromis. Będzie mi też brak całej infrastruktury, którą zorganizował: repozytorium, stron webowych serwera ftp i innych." Strona domowa projektu to http://www.linuxppc.org.

Holger Kiehl i inni używali łaty Bena Greeara aby uzyskać wsparcie dla sieci wirtualnych VLAN w jądrze 2.4. Holger stwierdził, że od dłuższego czasu nie było problemu z patchami i zapytał dlaczego nie zostały one włączone do drzewa Linusa. Ben, autor łaty, odpowiedział:

Odbyłem dzisiaj owocną dyskusję z Davem Millerem; do rozwiązania pozostaje jeszcze jedna sprawa, zanim wprowadzenie mojej łaty 802.1Q VLAN do jądra będzie mogło być brane pod uwagę:

Czy VLAN powinny być urządzeniami, czy może też czymś innym?

Zdecydowanie uważam, że z wielu powodów powinny być one urządzeniami.

Dzięki temu integracja z narzędziami przestrzeni użytkownika (ip, ifconfig, arp...) staje się rzeczą trywialną.
Jest to rozwiązanie logicznie poprawne, VLAN jest urządzeniem sieciowym '(net_) device' i we wszelkich działaniach zachowuje się właśnie jak urządzenie sieciowe.
Nie powoduje ono żadnego pogorszenia osiągów szybkiej trasy o którym bym wiedział. Jedyne spowolnienie związane jest z liniowym wyszukiwaniem nazwy urządzenia według nazwy (lub id??). Może to być łatwo rozwiązane poprzez wykomentowanie listy, jeżeli zajdzie taka potrzeba.
Oba patche VLAN używały od początku VLAN jako urządzeñ, i nie widać żadnego złego wpływu tego rozwiązania, który mógłby być złagodzony poprzez użycie jakiejś innej architektury.

Ważne jest jednak, aby cała społeczność zgodziła się w mniejszym lub większym stopniu, że moje (oraz wielu innych osób, zgadzających sie ze mną) argumenty są rozsądne. Prosimy więc, zgłoście teraz swoje reklamacje... lub już zawsze łatajcie ręcznie!

Oczywiście, także wszelkie inne skargi lub sugestie dotyczące kodu VLAN powinny zostać zgłoszone!

Jeżeli chcesz obejrzeć patcha, pobierz wersję 1.0.1 z mojej strony vlan: http://scry.wanfear.com/~greear/vlan.html Wkrótce opublikuję nową wersję, w której kod szybkiego wyszukiwania urządzeñ (the fast-dev-lookup code) (który już został wy#ifdef'owany) zostanie całkowicie usunięty, zgodnie z życzeniem Dave'a.

Grupka ludzi od razu poparła rozwiązanie traktujące VLAN jako urządzenia, a Dax Kelson wtrącił: "Koncepcyjnie, traktowanie VLAN jako urządzeñ sieciowych jest uproszczeniem." Jednak David S. Miller odpowiedział: "Sprawy związane z samym rozwiązaniem technicznym muszą być brane pod uwagę tak samo jak sprawa "czy to wygląda ładnie"." Gleb Natapov argumentował: "Jak mogę wprowadzić warstwę pośrednią pomiędzy L3 i L2 w bieżącym jądrze? To właśnie na tym polega VLAN. Jedyny sposób w jaki to można dzisiaj wykonać to założyć, że L3 jest urządzeniem sieciowym, wykonać swoje zadanie (dodając nagłówek VLAN) oraz zadanie L2 (zbudowanie nagłówka ethernetowego) i skierowanie pakietu do urządzenia głównego w celu przekazania. To właśnie robi moduł ipip, to właśnie robi moduł bonding oraz wiele innych. Dzieje się tak dlatego, że L1 i L2 za bardzo się sprzęgły w obecnym jądrze. Tak naprawdę, wprowadzenie nowego protokołu L2 jest prawie niemożliwe bez zmiany struktury net_device. Należałoby coś zrobić ze schematem L1+L2, a do tego czasu, udawanie urządzenia sieciowego (net_device) jest jedynym rozwiązaniem jeżeli VLAN ma być przezroczysty dla protokołów L3. Jeżeli zastosowanie VLAN miałoby się ograniczyć jedynie do warstwy IP, mogłoby to być oczywiście rozwiązane inaczej."

Brak z tym nie dyskutował, jednak Ben odpowiedział, że traktowanie VLAN jako urządzenia było "najprostszym rozwiązaniem. Dzięki temu nie musiałem ruszać warstwy 3 i nie musiałem łatać jakichkolwiek programów przestrzeni użytkownika, takich jak ip lub ifconfig." Dodał on: "Nie jestem nawet pewien, czy wypowiadający negatywne opinie mieli kiedykolwiek jakiś inny pomysł, nie podobała im się po prostu duża liczba interfejsów. Początkowo miały miejsce oskarżenia o niewydolność, jednak wydaje się, że poza rzeczami takimi jak 'ip' oraz ifconfig, nie istnieją poważne problemy z wydajnościa o których bym coś wiedział."

Alan Cox ogłosił, że jądro 2.2.20-pre4 ujrzało światło dzienne i dodał: "Linux 2.2 przechodzi teraz w stan błogiego odpoczynku. Łaty z fajnymi pomysłami będą teraz włączane do 2.4. W ogólności wszystkie nowe sterowniki będą włączane w 2.4 (a do 2.2 przejdą dopiero, gdy w 2.4 okaże się, że są stabilne). Możecie się spodziewać, że będę teraz bardzo wybredny w odniesieniu do jakichkolwiek zmian w kodzie."

Zack Weinberg zakomunikował: "W kodzie implementującym nienazwane łącza w 2.2 nie jest sprawdzany kod powrotu z funkcji copy_*_user. Może to prowadzić do niezawuażonej utraty danych." Ten błąd był już usunięty w 2.4, jak mówił Zack, ponieważ ten kawałek kodu został napisany całkowicie od nowa. Dodatkowo dołączył patch do jądra 2.2.18 i późniejszych, i zgłosił, że nie miał żadnych problemów na swojej maszynie od momentu zaaplikowania łaty -- 13 maja.

David S. Miller przypomniał sobie, że już jakiś czas temu Andrew Tridgell zauważył ten problem, ale dziwnym trafem nie mógł sobie przypomnieć, dlaczego uznali, że nie trzeba tefo poprawiać. Andrew odparł, że była to decyzja Linusa Torvaldsa. Dodał jeszcze: "Linus nie chciał poprawić błędu w pipe.c dopóki copy_from_user nie zostałoby poprawione na wszystkich architekturach" [...] " Nie chciał abyśmy poprawili tylko ten jeden przypadek i olali wszystkie inne."

Zack także odpowiedział Davidovi, pytając czemu w takim razie błąd został poprawiony w 2.4 a nie w 2.2; w szczególności spytał: "Czyżby osobliwy rodzaj zgodności?" David odpowiedział tajemniczo: "Nie raczej pewien rodzaj ,,to i tak nie ma znaczenia'' problemu." Zack się nie zgodził z tym, mówiąc, że taka zmiana pomiędzy 2.2 a 2.4 może spowodować zmianę zachowania niektórych aplikacji z przestrzeni użytkownika. Linus opdarł:

Hej, mogę Ci pokazać przykład kodu, który będzie się zachowywał różnie w zależności od użytych flag kompilatora, czy czegoś takiego.

Podpowiedź: ,,niezdefiniowane zachowanie''.

Jeśli ktoś przekazuje zły wskaźnik do funkcji systemowej, wchodzisz na teren obowiązywania reguły: ,,jądro _może_ być miłe dla Ciebie, ale równie dobrze może uznać, że jesteś ciołkiem i zakomunikować Ci że wszystko jest w porządku''.

Nie ma niczego takiego jak ,,stracone dane''. To ty spieprzyłeś i wyrzuciłeś swoje dane w błoto. Nie wiñ za to jądra.

Miles Lane podał odnośnik do wywiadu z Billem Gatesem, w którym to Bill przedstawił swoje oficjalne stanowisko dotyczące GPL. Niektórzy ludzie naigrywali się z Billa mowiącego: "Nie wydaje mi się aby kiedykolwiek ktoś prosił o kod źródłowy programu Word. Jeżeli by pytali, to dalibyśmy im ten kod. Ale nie jest to życzenie typowe." Pojawiły się komentarze typu ,,Ja chciałbym kopię, Bill'', dopóki Gerhard Mack nie zauważył: "Zabawna sprawa, ale dając wam ten kod, mogliby was nieźle załatwić w temacie dzieł opensource. Jeżeli myślicie, że GPL jest wirusowe, to nie widzieliście jeszcze ,,shared source'' - źródła współdzielone.. przynajmniej GPL ma zastosowanie tylko do dzieł pochodnych." Miles dodał:

To jest najlepsze. Udałem się na stronę Microsoftu próbując odnaleźć egzemplarz ich Licencji Oprogramowania Współdzielonego lub coś podobnego. Znalazłem tylko bełkot Craiga Mundie oraz trochę krytyki GPL:

http://www.microsoft.com/business/licensing/sharedsource.asp

Jak możemy ocenić, czy jest sens prosić Billa G. o kod źródłowy programu Word, jeżeli nie pokażą nam nawet zniweczonej licencji? Podejrzewam, że "Licencja Oprogramowania Współdzielonego" NIE istnieje. A jeżeli nawet istnieje, to Microsoft nie chce aby ktokolwiek ją zobaczył, ponieważ pozwoliłoby to na bezpośrednie porównanie z GPL, LGPL itd. Broñ Boże jabłka porównywać z jabłkami!

Wydaje się, że mają tylko mieszaninę różnych metod ,,współdzielenia'' kodu źródłowego.

Microsoft stwierdza jakie prawa chce zapewnić każdej z tych kategorii programistów/użytkowników, a potem w niewiarygodny sposób ogranicza wolność kogokolwiek kto widział ich kod do zmian, portowania lub użytkowania kodu w jakikolwiek sposób. Wydaje mi się, że cieszą się ze studentów koñczących szkoły oglądających kod NT, jako że chcą oni aby naprawdę bystrzy ludzie przyzwyczaili się do używania NT bez przerwy, a potem ukoñczyli szkołę i wstąpili w szeregi Microsoftu.

Wydaje mi się, że jeżeli poprosisz o kod źródłowy, zdecydują czy chcą ci go pokazać, potem zmuszą cię do wyrzeczenia się swego życia (tak jak wolności do pracowania nad kodem choćby mgliście przypominającym kod który ci pokażą) a potem pozwą cię, doprowadzając do bankructwa lub ugody jeżeli tylko odetchniesz w sposób jaki im się nie podoba.

W koñcu Alexander Viro stwierdził, że cała dyskusja jest nie na temat i wątek się urwał.

W trakcie dyskusji, Linus Torvalds powiedział o proponowanej łacie, "jeżeli o mnie chodzi to ten problem skoñczy się dopiero w 2.5.x (i nie martwcie się, wydaje się, że 2.5.x będzie otwarte w ciągu tygodnia albo dwóch, nie mówimy więc o długim czasie)."

Wan Hing Wah spytał o wsparcie dla GPIB w Linuksie. Znalazł sterownik, ale ostatnia wersja wydawała się pochodzić z 1999 roku i zastanawiał się czy cokolwiek więcej zostało ostatnio zrobione. Richard B. Johnson odpowiedział:

GPIB jest w znacznym stopniu zależne od urządzenia. Jakiej płyty chcesz użyć? National Instruments ma tak zwany sterownik dla ich TNT4882 na ich stronie. Nigdy mi się nie udało nawet tego skompilować, co dopiero zmusić do działania.

Mam sterownik napisany dla tego chipa. Nie jest na licencji GPL, ale mógłby być gdyby pojawiło się zainteresowanie. W każdym wypadku, mogę wysłać Ci źródła do wypróbowania. Nie publikuj ich tylko jeszcze. Daj mi znać, bo przydałby się dodatkowy wkład w testy. Innymi słowy, jeśli zostanę zapytany, powiem po prostu, że pomagasz testować sterownik...

James Lamann miał moduł do 2.0/2.2, który był rozwijany przez firmę, która już nie istnieje na rynku i chciał przenieść go na 2.4; miał wszystkie źródła, ale był ciekaw, czy istnieje dokumentacja problemów, które pojawiają się w trakcie prenoszenia z wcześniejszych wersji na 2.4.

Timur Tabi podejrzewał, że nie ma takiego dokumentu, ale Richard B. Johnson pokusił się o następującą prezentację:

Na początek:

wait_queue_head_t Teraz zdefiniowane. Możesz zrobić '#if !defined(...)` i sprawić, że zmiany w kodzie będą wstecznie zgodne

Makro, THIS_MODULE jest teraz pierwszym polem struktury file_operations.

Include <linux/init.h> typ danych __init dla jednorazowej inicjalizacji kodu lub danych. To jest nowe, zatem nie jest zgodne ,,w tył''.

Inicjalizacja explicite spin-locks, SPIN_LOCK_UNLOCKED i/lub spin_lock_init(spinlock_t *); Jeśli to naprawisz, będzie zgodne.

ioremap() i przyjaciele są teraz wymagane nawet dla rzeczy używających niewiele pamięci. Nie możesz dłużej używać tego przy pomocy pojedynczego wskaźnika, musisz używać readl()/writel(), itp., żeby właściwie odczytać wartość. Jeśli to naprawisz, będzie zgodne.

Te zmiany powinny spowodować, że twój moduł się skompiluje (albo chociaż prawie)

Jonathan Corbet dodał, że jego nowa wersja ,,Linux Device Drivers'' będzie wypuszczona w ciągu tygodnia albo dwóch (i dostępna w sieci niedługo później) i albo rozwiąże problemy z przenoszeniem, albo niestety nie spełni swojej misji.

Albert D. Cahalan zauważył, że system plików FAT32 jest niespodziewanie zgodny z algorytmem Phase Tree, który umożliwia mu oferowanie pełnej integralności danych, lepszej niż w typowych systemach plików z księgowaniem. Daniel Phillips odpowiedział, "Tak, FAT jest tym co zainspirowało mnie do rozwijania tego algorytmu. Jednakże, dwa słowa: 'utracone klastry'. Teraz to może być tylko szczegół implementacyjny ;-) " Albert odpowiedział:

Jakie utracone klastry?

Ustaw 8 bit "flag" (A_BF_BPBExtFlags na Microsoft) żeby wyłączyć mirrorowanie FAT. Wówczas 4 mlodsze bity oznaczają która kopia FAT ma być użyta.

Przypuśćmy, że mamy 2 kopie FAT, tak jak to zwykle jest (było?). Nazwę je X i Y. Podczas montowania systemu plików uniemożliwiamy mirrorowanie FAT i zaznaczamy FAT X jako aktywną.

Teraz możemy dokonywać zmian w FAT Y bez naruszania integralności systemu plików. Windows nie będzie używał FAT Y. Tak jak zwykle, w algorytmie phase-tree, używamy wolnego miejsca do tworzenia nowej struktury, obok starej.

Czas na zmianę fazy:

Mamy FAT Y, aktualnie nieaktywny, uaktualniony na dysku. FAT X jest aktywny; opisuje bieżący stan dysku. Mamy nowy katalog główny na dysku, w wolnym miejscu. Mamy nowy sektor informacyjny systemu plików na dysku, w wolnym miejscu.

Zapisujemy pojedynczy sektor, wtedy:

FAT X staje się nieaktywny i nie nie będzie używany przez Windows. FAT Y staje się aktywny; opisuje nowy stan dysku. Stary katalog główny jest zaznaczony jako wolny na FAT Y. Dobrze! Stary sektor informacyjny jest zaznaczony jako wolny na FAT Y. Dobrze!

Jak tylko superblok idzie na dysk, FAT X może być również zapisany.

Olivier Galibert spytał, "Jaki jest Właściwy Sposób[tm] w 2.4.6 na zaalokowanie 16Mb przy stronach 4K tak żeby dostać adres szyny pci dla każdej strony? Łatwiej gdy są wirtualnie niesfragmentowane, ale to nie jest konieczne. IIRC, stary trick vmalloc-a-potem-przejdź-po-tablicy-stron obecnie nie wydaje się być dobry." Alan Cox odpowiedział, "Jeśli chcesz mieć to wirtualnie niesfragmentowane skopiuj kod z bttv, który ,,wypadł z gry'' a który jest teraz w około 8 sterownikach w jądrze. Jeśli nie jest Ci to potrzebne możesz po prostu zmapować przestrzeñ użytkownika i użyć kiovecs -- co z wielu powodów jest bardziej eleganckie. " Riley Williams spytał czy możnaby przerobić kod bttv tak by był standardową procedurą, która może być wołana przez każdy sterownik który jej potrzebuje, ale Alan uśmiechnął się, "Możnaby, ale podjerzewam, że Linus nie chciałby przyjąć takiego rozwiązania, bo mogłoby to zachęcić ludzi do używania tegoż rozwiązania 8) "


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

1.	15 Jun 2001 - 22 Jun 2001	(4 posts)	Stan prac nad sterownikiem do EEPRO100/S
2.	17 Jun 2001 - 19 Jun 2001	(3 posts)	Nowy maintainer dla wersji Linuksa na PPC
3.	19 Jun 2001 - 22 Jun 2001	(20 posts)	Stan prac nad wsparciem dla VLAN
4.	19 Jun 2001 - 21 Jun 2001	(14 posts)	Rozgrzewka przez 2.5
5.	19 Jun 2001 - 20 Jun 2001	(12 posts)	Różnice w zachowaniu 2.2 i 2.4
6.	20 Jun 2001 - 23 Jun 2001	(7 posts)	Microsoft a licencjonowanie źródeł
7.	21 Jun 2001 - 22 Jun 2001	(13 posts)	Linus ocenia, że jeszcze 2 tygodnie do 2.5.0
8.	22 Jun 2001 - 25 Jun 2001	(5 posts)	Status wsparcia dla GPIB
9.	23 Jun 2001 - 26 Jun 2001	(7 posts)	Przenoszenie z 2.0/2.2 na 2.4
10.	24 Jun 2001 - 25 Jun 2001	(5 posts)	FAT32 dobry do księgowania?
11.	27 Jun 2001	(4 posts)	Alokowanie sfragmentowanej pamięci

Kernel Traffic #124 For 2 Jul 2001

By Zack Brown

Translated By: Maja Królikowska , Miłosz Chmiel and Paweł Kot