Ovladače v user-space (aneb mílovými kroky k mikrojádru) (diskuse)

[Käyttäjä 11133]

Sice jsem čekal nějaké vícetechnické poznámky, ale i tak hezký blogpost. Díky.

[Luk]

Vícetechnické? Co si pod tím představit?

[Josef Kufner]

Ňáký čísla, nesrozumitelná dlouhá slova, složitě popisovat jednoduché věci, … a tak všelijak.

[Käyttäjä 11133]

Dostupné možnosti, popis API a tak

[Luk]

Popis API ... k čemu? K FUSE? To by šlo (třeba o tom někdy něco napíšu). Ale k něčemu, co (zatím) neexistuje...

[Käyttäjä 11133]

Ale člověk, který si přečte nadpis blogu nemůže vědět, že to zatím neexistuje. To zjistí až po přečtení blogu.

[Billy The Pilgrim]

Mikrokernel sice zni lakave, ale tak jak to tu popisujete pomerne dost hrozi, ze system skonci ve stavu "a la M$" - ke kazdemu novejsimu zelezu binarni drivery prelozene primo od vyrobce proti nejakemu univerzalnimu rozhrani.

[Luk]

Je otázka, co je lepší. Jestli binární drivery od výrobce (které ovšem - narozdíl od reality na Windows - při chybě nesestřelí celý systém), nebo žádné drivery či nechutné bastly.

Neříkám, že by tento stav byl optimální. Jenže to musíme brát realisticky. Že bude driver jako uživatelský program, ještě neznamená, že nemusí být svobodný. Ostatně většina implementací filesystémů pro FUSE svobodná je.

[MJ]

Je otázka, co je lepší. Jestli binární drivery od výrobce (které ovšem - narozdíl od reality na Windows - při chybě nesestřelí celý systém), nebo žádné drivery či nechutné bastly.

Možná je lepší nemít žádné drivery a uživatelům tak na rovinu říci, že je to hardware, který není pořádně podporovaný. Není nic horšího, než když si uživatel koupí nějaký HW, protože se kdesi dočetl, že se dá nějakým pochybným způsobem (binární modul od výrobce, ndiswrapper a spol.) pod Linuxem rozchodit, a pak zjistí, že funguje jen tak napůl, nebo že sice funguje, ale jen s 32-bitovým jádrem, zatímco on potřebuje 64-bitové, a tak dále. Takových problémů je už teď přespříliš a zavedením userspacových ovladačů by se nejspíš ještě řádově zhoršily.

Microsofti stále více propagují certifikované drivery (a mají k tomu dobré důvody -- mnohé drivery, které stvoří výrobci hardwaru, jsou opravdu strašlivé bastly), Linux něco takového má už od svého vzniku: driver, který se dostal do jádra Ono to opravdu funguje: většina driverů, které jsem potkal a které nebyly začleněné do kernelu, byla buďto zatím ve vývoji, nebo to byly takové bastly, že by s nimi každý soudný kernelový hacker dotyčného autora hnal až někam k severnímu pólu (tj. co nejdál od tučnáků ).

[Jardík]

Jakmile budou pro fuse proprietární moduly, přijde Linus, přidá do jádra následující kód:

if (strcmp(mod->name, "fuse") == 0)
	add_taint_module(mod, TAINT_PROPRIETARY_MODULE);

Pak se mu nedostane EXPORT_SYMBOL_GPL a dopadne to stejně jako s ndiswrapperem. A jestli ne, bude to nefér.

[Luk]

To by Linus popřel sám sebe. Napsal totiž toto:

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".

A FUSE filesystém není nic jiného než "user program". Systémová volání nepoužívá přímo, nýbrž přes knihovnu libfuse, která je pod LGPL - jediným požadavkem tedy je, že pokud bude mít implementace proprietární licenci, musí se linkovat dynamicky.

[Abraxis]

Ach jo... Clovece, precti si teorii OS, nez zacnes neco povidat o mikrojadru. Mikrojadro = v podstate je v kernelu jenom predavani zprav a mozna sprava pameti. NIC VIC. K tomuto Linux NIKDY nedospeje...

[Luk]

K tomuto Linux NIKDY nedospeje...

Never say never Před pár lety byl Linux prakticky jen mrtvé jádro (nepočítám-li obsluhu přerušení). Dnes obsahuje již desítky jaderných procesů (v adresním prostoru jádra) a několik zcela samostatných procesů. Další krok byl učiněn implementací FUSE - zanedlouho může být většina filesystémů v user-space. A tak to může pokračovat dál, až ke skutečnému mikrojádru.

[Michal Kubeček]

Jestli ono to nebude spíš tak, že jak dokonale čisté mikrojádro, tak dokonale čistý monolit mají své zásadní nevýhody, takže vývoj spěje k něčemu mezi nimi…

[alblaho]

To je jisté. Prostě místo toho, že všechny ovladače budou v userspace (resp extra proces), tak tam budou jen ty, u kterých je pro to důvod (licence, nebezpečnost, ...)

[Josef Kufner]

Mno, spíš bych řekl, že ty nebezpečné půjdou jen jako první. Přecejen, ladit démona je daleko jednodušší a pohodlnější, než ladit jaderný modul.

[alblaho]

Hlavně to přinese pořádné stabilní api. Takhle člověk napíše modul pro 2.6.5 a vyšší a na 2.6.10 to přestane být kompilovatelné, pač pánové změní nějaké "vnitřní" funkce.

[alblaho]

Ještě mě napadla myšlenka, jestli pověstné výkonové manko mikrokernelových systémů nepůjde setřít multijádrovými (8 a víc) procesory. Zkusím si to promyslet, až budu odpočatý.

[zde]

> jestli pověstné výkonové manko mikrokernelových systémů nepůjde setřít multijádrovými (8 a víc) procesory. Zkusím si to promyslet, až budu odpočatý.

Zajímavá úvaha.. bohužel si myslím že to moc nepomůže. Pokud bude počet jader větší než počet aktivních adresních prostorů, tak se sice ušetří pomalé přepínání kontextů, ale naskočí IPC latence, které jsou IMHO výrazně horší než přepínání adresního prostoru u singlecore.

[MJ]

Jo jo, ve skutečnosti rozhazování spolu komunikujících procesů mezi víc procesorů spíš ublíží, protože zatímco předtím si při troše štěstí vyměňovaly data uvnitř jedné L1 cache, takhle se budou přenášet přes řádově pomalejší sběrnici mezi procesory.

[michich]

FUSE je skvělá vychytávka, to bezpochyby.

Možnost přesunutí i některých ovladačů hardware do userspace může vypadat na první pohled taky zajímavě, ale ve skutečnosti to s nimi nebude tak růžové. Domnívat se, že chyba v userspace ovladači nemůže sestřelit celý systém, je omyl. Ovladač musí mít možnost dělat si s hardwarem, který má řídit, co chce. Blbě řízený hardware se může pěkně splašit. U FUSE tento problém nevzniká. FUSE proces lze také kdykoliv sestřelit, což u ovladače hardware není vůbec zaručeno.

A rozhodně nechci zažít, že kvůli možnosti dělat ovladače v userspace začnou výrobci HW ztrácet motivaci pro zveřejňování HW specifikací a tvorbu svobodných ovladačů. Pak se nám systémy začnou plnit plnit dalšími proprietárními, nekontrolovatelnými, neportabilními bloby. To, že budou v userspace místo v kernelu, je už úplně jedno.

[MJ]

Ono na "hračky" typu ftpfs je FUSE pěkné, ale zkuste si v userspace implementovat takovou ext2 nebo libovolný FS, u kterého čekáte, že bude aspoň trochu rychlý

[Luk]

NTFS je implementovaný přes FUSE (ntfs-3g). A co jsem četl a taky něco málo zkoušel (jen čtení, i když umí také zápis), tak na tom s rychlostí není špatně.

[David Watzke]

Jde to, právě jsem zkusil:

pv < /mnt/win/pagefile.sys > /dev/null

a jelo to kolem 24-26 MB/s.

[MJ]

No jo, ale ext3 dneska na dosti obyčejném hardwaru dělá něco kolem 60MB/s, na slušnějším pak třeba také 300MB/s. Takový rozdíl rozhodně za trochu pohodlí vyměnit nehodlám :)

(Mimochodem, také by bylo zajímavé se podívat, jak moc čtení z FUSE zatěžuje procesor, tipoval bych, že daleko více než z klasických FS.)

[zde]

Hmm, a co dělá ten pv? Se bojím že test filesystému čtením jednoho souboru skoro nic neřekne, ovladač FS jej pouze za minimální režie CPU namapuje do page cache, a pak se o vše stará VFS, nikoliv FS. Kde bude rozdíl je parsování adresářových položek- hodně volání, málo I/O, tam se režie userspace kódu projeví spíš.

[Luk]

Čistě ze zvědavosti jsem udělal malý test. Jednalo se o kopírování adresáře s různými podadresáři, celkem cca 6000 souborů, 550 MB dat. Při každém pokusu se data tahala přímo z disku (na začátku prázdná cache).

NTFS (FUSE) -> ext3

real    1m58.596s
user    0m0.275s
sys     0m6.035s

ext3 -> VFAT

real    3m8.140s
user    0m0.270s
sys     0m31.652s

NTFS (FUSE) -> VFAT

real    3m54.498s
user    0m0.219s
sys     0m29.187s

Nepovažuji to samozřejmě za žádný reprezentativní test, ale je snad jasné, že takový problém s tím nebude. Test spíš prokázal ukrutnou pomalost zápisu na VFAT