Jaderné noviny 172

2. 7. 2002 | Leoš Literák

Články - Jaderné noviny 172  

Rozpory nad rekurzí, nová implementace mutexu a binární soubory ve stromu jádra.

Jaderné noviny 172 Rozpory nad rekurzí, nová implementace mutexu a binární soubory ve stromu jádra.

Do konference přišlo celkem 1483 emailů, nejvíce psali David S. Miller, Martin Dalecki a Andrew Morton.

Nová implementace mutexu, 45 emailů

Rusty Russell zaslal nějaké patche implementující /dev/futex, souborově orientovaný mutex. Ten může být otevřen, zavřen a čten normálními systémovými voláními, což podle něj je velmi výhodné pro aplikace. Ale Linus Torvalds byl jiného názoru, neboť křičel:

STOP! Co je to za šílenství? Máš k dispozici zatracené systémové volání pro mutex, nezaváděj tedy takové svinstvo do /dev. Copak vytváříme roure otevřením /dev/pipe? Ne. Máme hlavní a vedlejší [major a minor] čísla pro sokety a plníme jimi /dev? Ne. A důsledkem toho s nimi nikdy nebyly problémy pro administrátory. Existuje přece systémové volání ke svázání fd s futexem, takže používej jediný správný způsob a odvrhni ten stupidní a hrozný /dev/futex, který způsobí bolest tobě i aministrátorům, extra kód a červený puntík za hloupost.

Rusty však cítil, že aspoň pro síťové programování soketové API není nejlepší model pro kopírování (Alan Cox měl podobný názor) a Peter Wechtler navrhnul používat /proc/futex, což se vyvine v méně administrátorské práce, čistší rozhraní a Al Viro to bude mít rád, neboť se to podobá Plan9 či QNX6. Ale Linus nesouhlasil:

Řekněte mi jedinou výhodu toho, když exportujeme futex jako jméno souboru. Hlavní myšlenkou "všechno je soubor" nejsou názvy souborů (ve skutečnosti sokety a roury ukazují, že soubor a jméno souboru nemají nic společného), ale fakt, že můžeš použít společné nástroje na různé typy souborů. Ale neexistuje jediný rozumný důvod otevírat /dev/futex z shellových souborů, protože z nich nic nedostaneš. Stejně musíš navázat fd na skutečný objekt. Ve stručnosti, /dev/futex je bezvýznamný. Žije skrze systémové volání a exportováním jeho jména jen způsobíte problémy lidem, kteří nechtějí připojovat /proc nebo nemají ten soubor v /dev.

Rusty se však nevzdal a pokusil se implementovat futexy v souborovém systém sám. Použil proto kód ze sockfs a následně debata směrovala do technických detailů a diskusí nad sdílením kódu mezi souborovými systémy.

Binární soubory ve stromu jádra, 6 emailů

Keith Owens oznámil, že díky kbuildu 2.5 byl schopen detekovat binární soubory ve zdrojácích jádra. Poslal jejich soupis a dodal, že toto je výhoda build systému, který ví o všem. Různí lidé se pak hlásili k těmto souborům s tím, že byly začleněny omylem a mohou být bezpečně smazány.

Rozpory nad rekurzí, 12 emailů

Andries Brouwer oznámil implementaci nerekurzivního řešení [resolution] symbolických odkazů. Ale Linus odvětil, že nic takového neexistuje. Symlinky jsou už od nátury rekurzivní, protože musíme být schopni vyhledat symlink uprostřed jiného. Takže buď použijeme rekurzi v C nebo ji linearizujeme ručně přes zásobník či linkovaný seznam. Obě metody jsou rekurzí, liší se jen mechanismus. Nevidím výhodu řešit to ručně, protože se nejedná o hlubokou rekurzi a i v případě ručního řešení musíš omezit hloubku zanoření, abys zabránil DoS útokům.

Andries poznamenal, že jeho patch umožní administrátorům zvolit si povolenou hloubku rekurze, takže se nemusí bát přetečení zásobníku. Daniel Phillips napsal Linusovi, že rekurzivní průchod sám o sobě způsobuje problémy. Spotřeba zásobníků najednou naroste na N*nejnenasytnější_ss a tak musíme počítat s nejhorším případem. Proto redukce N na 1 je velká věc. Navíc z praktického hlediska je pro vývojáře souborových systémů lepší rada: "toto nikdy nebude vyžadovat více než N bytů na zásobníku", než "toto nebude vyžadovat více než N bytů kromě symlinků, kdy se podívej na limit v rekurzivnich symlincích".

Ale Linus napsal, že průchod [trip] souborovým systémem sám o sobě není rekurzivní [LL: vážně? to jde?] V jeden čas je aktivní jen jedno vyhledání, takže zásobník je dobře omezen. Zásadně nejsem proti tomu, aby lidé testovali Andriesův patch, je mi to jedno. Protestuji proti náboženskému odporu vůči správnému programovacímu konstruktu (omezené rekurzi).

Ovšem Andries odvětil, že si nechtěl hrát se slovíčky a že je vidět, že Linus rozuměl, co měl na mysli nerekurzivní verzí. Funkce link_path_walk() z namei.c zavolá do_follow_link() v případě symlinku a tato rutina zavolá dentry->d_inode->i_op->follow_link(), například nfs_follow_link(), která zavolá vfs_follow_link(), která zavolá link_path_walk() atd. Takže vidíš, že v zásobníku N volání bude také N volání foofs_follow_link(). Takže v mé verzi rekurze metody nfs_follow_link() jsou skutečně rekurzivní: končí voláním sebe sama. Minulou neděli jsem ukázal demo, které vytahuje souborový systém ze smyčky. Takže řešení symlinku je stále rekurzivní, ale metoda foofs_follow_link() bude volána nejvýše jednou. Včera jsem zaslal patch, který se obejde bez rekurze úplně.

Linus reagoval na současný stav: Ano, ale podíval ses na ty rámce na zásobníku? Jedná se o 16 bytů pro ext2_follow_link, 20 bytů pro vfs_follow_link() a 56 bytů pro link_path_walk. A actual->follow_link uloží 8 bytů argumentů. Takže rekurze o úrovni 5 vyžaduje zhruba 500 bytů na zásobníku. A toto byl můj důvod: jediným rozdílem mezi oběma verzemi je, kde ty byty naalokuješ. Není nic špatného na tom, nechat toto rozhodnutí na kompilátoru. A rekurze o hloubce 5 je podstatně více, než lidé běžně používají. Pokus prodat mi tuto věc jako "rekurze je špatná a musí být zničena" na mně nefunguje.

Andries spráskl rukama a vysvětlil historii, která začala tím, že Checker nalezl velké proměnné na zásobníku a Checker měl potíže se správným výpočtem maximální velikosti zásobníku v případě rekurze. Tak jsem poznamenal, že by bylo jednoduché tuto rekurzi odstranit, o čemž Al pochyboval. Tak jsem udělal půlku práce a Al řekl, že to stále nic není, že úplné odstranění rekurze by bylo peklo. Tak jem to dokončil. Obyčejné demo a poslal jsem ti kopii. Mým tajným přáním je, že Al napíše, že můj kód je škaredý a obsahuje 17 chyb, ale on jej přepsal elegantním způsobem do rychlého a udržovateného stavu. Ten patch nebyl míněn pro začlenění do jádra, ale pro diskusi s Alem. Linus nereagoval.

Tento článek vychází ze seriálu Kernel Traffic (http://kt.zork.net) a je zveřejněn pod licenci GPL verze 2.

Diskuse k tomuto článku

[deda.jabko]

pri prekladu by to chtelo vychytat nektere anglicke konstrukce - clovekovi, ktery pouziva anglictinu denne, to mozna ani neprijde, ale misty to opravdu rve usi resp. oci

[beecher]

No, je sice pravda, ze jsou tam pouzity anglikanismy (nebo jak to rict), ale uvedomte si, ze pokud nekdo cte Jadrince (4. p. od Jadrinec, jak ja rikam Jadernym novinam :o) ), tak to neni nejaky BFU, ponejhur uplny zacatecnik s PC. Tudiz my to prezijeme, ne?

Jinak (ted to neberte jako urazku) to tu bude vypadat jako na Zive (nebo snad Mrtve???), kde se lide na PC Tuningu (stejny rank jako ABC Linuxu ale na HW) hadaji o cestinu... Des...

BTW Zkuste se nekdy poslechnout pri rozhovoru s clovekem pocitacove zdatnejsim... Verte, ze tech anglikanismu tam bude "privela"...

[Leoš Literák]

ahoj, ja si to uvedomuji, ale casto neznam (ci neexistuje) cesky nazev. vetsinou to resim tak, ze napisu preklad a v zavorce puvodni termin.

kazdopadne: kdykoliv narazite na chybny ci neuplny preklad, napiste prosim angicly vyraz a jeho cesky preklad do diskusniho fora, at se poucim a nedelam stejne chyby i priste