FUSE v jádře 2.6.14 (?)
Po neúspěšném březnovém pokusu o začlenění do jádra 2.6.12 bude FUSE začleněno s vysokou pravděpodobností do následující verze 2.6.14. Největším problémem, který bránil jeho přijetí správcem řady 2.6 Andrew Mortonem, byly „triky“ s právy, zejména že uživatel, který připojí soubory (a žádný jiný, ani root), k nim má neomezený přístup, i když práva a vlastnictví souborů říkají něco jiného.
Problém sice zůstává nevyřešen, protože nikdo nepřišel s řešením vyhovujícím oběma stranám, ale Andrew už má dost argumentů pro zařazení do hlavního stromu zdrojových kódů jádra. Až někdo přijde na to, jak zbývající problémy vyřešit, mohou se vyřešit i tam.
FUSE (Filesystem in USErspace, fuse.sourceforge.net) je rozhraní jádra, které umožňuje implementovat souborové systémy v uživatelském prostoru, tedy ne jako součást jádra. To je výhodnější nejen z pohledu jednodušší implementace a nižšího ohrožení bezpečnosti systému, ale také například z důvodu vyhnutí se složitému procesu prosazování zařazení nového souborového systému do jádra... FUSE již nyní používají téměř tři desítky projektů vyvíjející nové souborové systémy, z nichž nejzajímavější jsou např. EncFS (šifrování), FunFS (lepší NFS) nebo třeba SshFS (co myslíte?).
Reiser4: zařadit do jádra, ano, či ne?
Hans Reiser, vedoucí týmu vyvíjejícího nevšední souborový systém Reiser4 (www.namesys.com/v4/v4.html), v polovině září znovu zažádal o jeho zařazení do hlavního stromu kódů jádra (mainline). Poprvé to bylo již v červenci 2003! Reiser4 je již delší dobu v experimentální sadě -mm Andrewa Mortona, začlenění do mainline však stále brání mnoho (chtělo by se říct nevyslyšených) výhrad jaderných vývojářů. Obligátní záležitostí je styl zdrojových kódů - podle Hanse v mnoha ohledech lepší než „standardní jaderný“ styl. Vývojáři si to nemyslí a argumentují tím, že zaběhnutý styl zvyšuje přehlednost kódu a umožňuje ostatním jej upravovat (aby se neopakovala situace s Reiser3).
Styl psaní kódu ale rozhodně není jediná a hlavní výtka. Vytýkáno je také používání starých funkcí, duplikování existujícího kódu a vůbec řešení některých věcí „po svém“. Problém s tzv. metasoubory (soubor je adresářem se soubory odpovídajícími atributům tohoto souboru), u nichž může dojít k zablokování celého systému, byl vyřešen prozatímním zrušením této vlastnosti. Co se kupodivu v poslední diskuzi neprobíralo, je pozoruhodný systém zásuvných modulů, umožňující jednoduché rozšiřování o další funkční vlastnosti (např. kompresi, šifrování, apod.). Nejen vývojáři by totiž tuto bezesporu užitečnou funkcionalitu uvítali spíše ve VFS, aby byla využitelná všemi souborovými systémy.
Na druhou stranu vývojáři Reiser4 úspěšně vyřešili přechod na 4kB zásobník a kód prý již neobsahuje žádnou známou nebo reportovanou chybu. A soudě podle reakcí uživatelů v různých diskuzích je většina pro zařazení tohoto výjimečného souborového systému do jádra (právě proto, že je tak novátorský). Výsledek je prozatím takový, že i přes obrovské úsilí vývojářů Reiser4 zbývá ještě dodělat pár (mj. zmíněných) věcí, což se stěží stihne do verze 2.6.14. Reiser4 by ale mohla být první věc zařazená do verze 2.6.15. Více se o souborovém systému Reiser4, o jeho návrhu, potenciálu a rozdílech oproti Reiser3, nebo o Hansi Reiserovi a jeho chystané novele, dočtete v rozhovoru s ním na kerneltrap.org/node/5654.
Implementace DCCP
Jednou z prvních věcí začleněných do následující verze 2.6.14 je linuxová implementace protokolu DCCP od A. Carvalho de Mela, I. McDonalda a dalších. Stane se tak první široce rozšířenou implementací tohoto nového protokolu a pomůže odhalit jeho případné mouchy. Zároveň s tímto kódem byly také zobecněny některé části síťové vrstvy jádra, které byly doposud využitelné jen pro TCP a UDP.
DCCP (Datagram Congestion Control Protocol, www.icir.org/kohler/dcp/) je, podobně jako UDP, datagramový protokol transportní síťové vrstvy, který ovšem obsahuje mechanismus ochrany proti zahlcení sítě. Zahlcení sítě internet hrozí ze strany rozmáhajících se proudových (streaming) aplikací, internetové telefonie, online hraní a dalších aplikací, pro které je důležitější rychlost doručení než spolehlivost, kterou poskytuje TCP. Proto využívají UDP, ale tento protokol na rozdíl od TCP neobsahuje žádný mechanismus ochrany proti zahlcení (při absenci jakéhokoliv spojení není způsob, jak reagovat na stav sítě). DCCP je proto také spojově orientovaný protokol (používá koncept „polovičních spojení“), vyžadující vytvoření spojení (3 pakety) před vlastním přenosem dat. DCCP obsahuje kromě ochrany proti zahlcení a správy spojení i vlastnosti jako minimalizace režie protokolu, odolnost proti útokům odepřením služby (DoS), bezproblémovost s firewally a další. Momentálně je jeho vývoj v IETF ve stavu návrhu (draft) RFC, ale do budoucna se doufá v přechod datově náročných aplikací z UDP na DCCP za účelem lepšího a férovějšího využití sítě. Více se o DCCP dozvíte např. na wlug.org.nz/DCCP.
Jan Outrata
Zdroj: www.kernel.org
