AbcLinuxu:/ Články / Jaderné noviny 243

Štítky: BSD, C, e-mail, emulace, FreeBSD, hardware, HTML, Intel, kernel, komunikace, Linux, ovladače, patch, práva, programování, RAID, software, textové editory, udev, Vim, web, Windows

Jaderné noviny 243

31. 12. 2003 | Robert Krátký | Jaderné noviny | 3989×

Nový projekt pro používání některých Windows ovladačů v Linuxu. Status udev. Grafy srovnávající testy 2.4 a 2.6. Změna mezi 2.4 a 2.6 při zacházení se SIGTRAP na x86.

Do konference přišlo celkem 1424 emailů, nejvíce jich poslali William Lee Irwin III, Andrew Morton a Linus Torvalds.

Nový projekt pro používání některých Windows ovladačů v Linuxu, 84 e-mailů

18. lis - 24. lis

Pontus Fuchs oznámil:

Protože někteří výrobci odmítají vydat specfikace nebo i binární linuxové ovladače ke svým WLAN kartám, rozhodl jsem se pokusit se vyřešit to sám vytvořením jaderného mudulu, který umí natáhnout Ndis (windows network driver API) ovladače. Nesnažím se implementovat kompletní Ndis API, ale pouze funkce potřebné ke zprovoznění těchto nepodporovaných karet.

Zatím to dobře funguje s mojí Broadcom 4301, ale rád bych navázal kontakt s lidmi, kteří mají podobné karty, a jsou ochotni se účastnit testování/hackování.

Více informací na: http://ndiswrapper.sourceforge.net/

Prosím vás! Nechci začínat flamewar o tom, jestli je dobré něco takového dělat. Jen se snažím řešit to, co mě pálí, a pochybuji, že by tento projekt změnil přístup Broadcomu k uživatelům Linuxu.

Christian Axelsson řekl, že to je výborný plán a Maciej Zenczykowski souhlasil, ale dodal:

Natahuješ ty ovladače do ring 0 (prostor kernelu)? Pokud vím, tak Linux podporuje pouze ring 0 (kernel) a 3 (uživatelský prostor). V tomto případě by však bylo ideální natahovat binární ovladače do ring 1 (nebo dokonce do uživatelského prostoru, kdyby to bylo možné...). Nemohu říct, že bych jakémukoliv binárnímu a/nebo windowsímu oladači důvěřoval, že mi něco neprovede s kernelem :). Sám ovladač může být bezchybný - ale je prostě navržen pro jiný operační systém, takže se snadno může přihodit něco neočekávaného.

Když už o tom mluvím, natahování binárních ovladačů do ring 1 by také asi bylo vhodné pro NV modul a jemu podobné. Ačkoliv netuším, jak náročné by bylo zprovoznit ring 1 (a jestli má vůbec cenu to dělat v ring 1 místo v ring 3 s iopl/ioparm) a jaký by byl výkonnostní pokles oproti ring 0.

Richard B. Johnson odpověděl:

Pracují ty NDIS ovladače v 32 bitovém prostředí? Některé berličky ano. Ty byly ovladačovým rozhraním reálného režimu DOSu k MS-DOSu. Teď existuje berlička na berličce nazývaná NDIS-6. Také používaly pascalský způsob volání, což mršilo C kód (je potřeba assembly wrapper).

Je to ztráta času. Proč klonovat microsoftí rozhraní pro ne-microsoftí operační systém, když těm zmetkům stejně nemůžeš povolit běžet v rámci kernelu?

Problémem u cizích binárních ovladačů není rozhraní ke kernelu. Linux má veřejné rozhraní, které je dobře zaběhlé a známé. Problém je, že jakýkoliv cizí ovladač může naprosto zmrvit kernel, ať už kvůli chybě nebo kvůli své stavbě. Takže cizí ovladače MUSÍ poskytnout zdrojové kódy, aby mohly být opraveny nebo postaveny do latě v případě, že se najdou problémy.

Status udev, 14 e-mailů

19. lis - 20. lis

Adrian Bunk poslal patch, který dokumentoval fakt, že udev není ve skutečnosti připraveno plně nahradit DevFS. Grek KH se zeptal, co Adrianovi v udev 006 chybí, a Martin Schlemmer odpověděl:

Hádám, že jde o větší podporu ovladačů, atd. Vstupní zařízení zdá se například zatím vůbec nemají podporu pro sysfs. Také plná podpora initramfs s udev a konfigurace udev.permissions tak, aby byla základní práva správně nastavena, by pomohlo lepšímu prosazení u uživatelů (bez potřeby udržovat /dev nebo bez počátečního úsilí pro ty, které ani tolik nezajímá, jak to funguje).

Řekněme prostě, že z toho, co jsem slyšel uživatele říkat, se největší překážkou jeví počáteční nastavení a zdánlivý 'nedostatek funkčnosti'.

Greg souhlasil, že větší podpora ovladačů by byla fajn, ale řekl, že ze strany udev pro to moc udělat nelze. Ale napsal Pro 2.6.1 mám připravených několik patchů, které poskytnou větší podporu ovladačů pro sysfs. O podpoře initramFS Greg řekl: Lidé udržující klibc kernel bk strom v něm mají dostatečnou podporu pro umístění udev do initramfs. Opět nic, co by bylo potřeba udělat v udev. Ohledně situace s udev.permissions Greg napsal: Od verze 006 jsou podporovány wildcards, takže je to otázka distribucí, které by měly pouze sestavit soubor s právy, který odpovídá jejich potřebám. Připustil, že udev ještě čeká hodně práce, aby bylo stabilní a vyspělé, ale z velké části už je teď použitelné :). A dodal, že hlavní úkol teď leží na distribucích, aby zapracovaly na správném nastavení pro používání udev.

Grafy srovnávající testy 2.4 a 2.6, 1 e-mail

21. lis

Cliff White napsal:

Pro ty, kteří mají rádi vizuální data, jsem vytvořil několik grafů srovnávajících různé STP testy. Pro účely srovnání jsem použil 2.6.0-test9 a 2.4.22/23-rc1. Data budou aktualizována po proběhnutí dalších testů.

Grafy jsou zde: ..reaim/compares/index.html

A další zde:

..reaim/index.html

Testovací kód Reaim: SourceForge projekt.

Změna mezi 2.4 a 2.6 při zacházení se SIGTRAP na x86, 7 e-mailů

22. lis - 24. lis

Daniel Barlow oznámil:

Mezi 2.4 (2.4.23-rc2) a 2.6 (2.6.0-test9) je změna při zacházení s "int 3" v rámci SIGTRAP handleru.

Ve 2.4 se zdá, že handler je rekurzívně znovu-zadáván. Ve 2.6 je úloha zabita spolu s dalšími, které sdílejí stejnou VM (nemluvím o threadovaných skupinách; mám nastaveno CLONE_PARENT a CLONE_VM, ale ne CLONE_THREAD).

Nejsem si jistý, jaká je správná odpověď, pokud to je skutečně určeno. Například o FreeBSD 5.1 mi bylo řečeno, že handler signálů běží až do dokončení a znovu je volán pouze při ukončení. Připadá mi, že takové chování je pravděpodobně více v souladu s principem nejmenšího překvapení. I když mě možná překvapují netypické věci.

Linus Torvalds potvrdil změnu mezi 2.4 a 2.6 a vysvětlil:

Základní změnou je následující:

Některé signály jsou "threadově synchronní", tj. thread bez nich nemůže pokračovat. Vlastně to dělá každá instrukční chyba, protože pouhé vrácení by obecně způsobilo, že by byla instrukce provedena znovu, což by skončilo se stejnou chybou.
Rozdíl mezi 2.4.x a 2.6.x je v tom, že v 2.4.x taková instrukce proletí blokem, takže i když je zablokuješ, stále se provádějí. V 2.6.x způsobí pokus o blokování threadově synchronního signálu zabití procesu s tím signálem ("nemůže být doručen, nemůže být ignorován, takže to alespoň řekneme uživateli").

Důvodem této změny je to, že chování ve 2.4 způsobuje ukrývání chyb a může být i příčinou nenadálých zatuhnutí v threadovaných programech. 2.6.0 provádí "Udělal jsi něco skutečně špatně, takže chcípni".

Ohledně samotné změny v kernelu poznamenal Paul Mackerras:

Občas se mi stane, že init proces narazí na instrukční chybu (často kvůli chybě v kernelu), jako například přístup na špatnou adresu. Na embedded platformách někdy nastane situace, kdy init použije instrukce s pohyblivou čárkou, ale CPU pohyblivou čárku nemá a kernel byl zkompilován bez emulace PČ. V takových situacích to vypadá, že systém zatuhne, protože init nedělá nic kromě přebírání stejného signálu stále dokola.

V tomto případě by signál nebyl určen k zablokování nebo ignorování, ale skončil by ignorován kvůli pravidlu, že "init nedostává žádné signály, které nechce". Dal bych přednost tomu, aby threadově synchronní signály zabily init nejsou-li řešeny, takže bychom alespoň dostali paniku s hláškou, která by říkala, co se pokazilo, místo aby se systém jen točil naprázdno.

Linus odpověděl:

Hmm.. Teď zrovna je zvláštní případ initu v doručovací cestě signálu, takže by bylo těžké něco takového udělat, protože pak už nevíme/je nám jedno, kdo signál poslal.

Mohli bychom zvláštní případ přesunout do odesílací cesty (a pak to provádět pouze pro "externí signály" a pro všechny interní bychom z initu zvláštní případ nedělali).

Hmm.. Jak se koukám na kód odesílání signálů, tak my ve skutečnosti děláme z "init" zvláštní případ - ale pouze v případě "kill -1". Kdyby byl test na "pid > 1" přesunut do "group_send_sig_info()", bylo by to asi hotovo.

Chceš-li něco takového zkusit, jen do toho. Jen to teď nebudu začleňovat ;).

V tu chvíli se H. Peter Anvin zeptal:

Proč vůbec z init děláme zvláštní případ?

Vypadá to, že jedinou věcí, kterou ještě nemůže init chtít po kernelu, je blokování SIGSTOP a SIGKILL a zdá se, že kdybych zabil (nebo pouze zastavil) init, tak bych měl prostě dostat paniku kernelu.

Jestli je něco, co by mělo být zvláštním případem, tak snad to, že init by měl mít možnost blokovat/zachycovat/ignorovat SIGSTOP/SIGKILL. Možná by to měla být schopnost?

Linus řekl, že kernel dělá z init zvláštní případ, ...

Protože závisí na existenci init. "init" je doslova zvláštní z pohledu kernelu, protože je to "kosič zombií" (což by, smím-li připojit, bylo výborné jméno pro rockovou skupinu).

Takže bez init by kernel neměl k čemu se vrátit, když zemře rodičovský proces, a byl by velmi nešťastný. Dříve to vlastně oopslo jádro.

UNIXová sémantika doslova vyžaduje, aby "getppid()" vracelo 1, když rodič zemře, a to je "current->p_parent->tgid". Takže musíme mít rodiče s pid 1, a proto je init zvláštní.

Jasně, mohli bychom mít další zvláštní případy (mohli bychom vytvořit jiný neviditelný proces s pid 1), ale faktem zůstává, že nějaký zvláštní případ je třeba. A může to prostě být "nemůžeš zabít init".

V originálu Kernel Traffic 243 vyšla navíc ještě tato témata: