Jaderné noviny - 23. 8. 2006

8. 9. 2006 | Robert Krátký | Jaderné noviny | 3453×

Aktuální verze jádra: 2.6.17.11. Stará jádra, nové kompilátory. Kevents a nová API.

Aktuální verze jádra: 2.6.17.11

Aktuální verze jádra je 2.6.17.11, vydaná 23. srpna. Jde o poměrně velkou sadu patchů s opravami mnoha závažných chyb. Předtím vyšla 22. srpna 2.6.17.10. Ta obsahovala tři bezpečnostní opravy: problém v SCTP kódu umožňující získání práv, narušení paměti v souborovém systému UDF a pád systému, který však mohl způsobit jen uživatel s určitými právy. 9. srpna vyšla verze 2.6.17.9, v níž byla jediná oprava bezpečnostní chyby týkající se PowerPC.

Aktuální předverze je i nadále 2.6.18-rc4. Linus si na dovolené udělal dost času na začlenění přibližně 100 patchů do hlavního repozitáře, jinak se v této oblasti nic moc zajímavého nedělo.

Aktuální verze -mm stromu je 2.6.18-rc4-mm2. Mezi nedávné změny patří sada patchů pro ochranu jaderného stacku [kernel stack protector] (označeno jako "bezpečnostní placebo"), možnost filtrovat výpisy jádra pomocnou aplikací a množství oprav.

Aktuální verze řady 2.4 je 2.4.33.2, vydaná 22. srpna. Obsahuje několik oprav, včetné té pro poslední bezpečnostní problém s SCTP. Předtím vyšla 19. srpna 2.4.33.1 s dvojicí dalších bezpečnostních oprav.

Prvním krokem k 2.4.34 je 2.4.34-pre1 s další malou dávkou oprav (vizte také níže).

Stará jádra, nové kompilátory

Během dlouhodobého správcování řady 2.4 převedl Marcelo Tosatti jádro 2.4 do režimu údržby, při kterém bylo uvažováno o začlenění pouze těch nejdůležitějších oprav. Pro některé lidi to možná bylo až příliš - Marcelo se přeci jen musel věnovat i jiným věcem kromě správy 2.4. Přesto však málokdo očekával nějaké zásadní změny, když po vydání 2.4.33 správcování převzal Willy Tarreau. Proč se v tom teď vrtat?

Takže Willyho oznámení o 2.4.34-pre1 vzbudilo určité pochybnosti. Předverze sama o sobě obsahuje relativně malý počet přesně takových patchů, jaké by člověk očekával. Ale v oznámení se mluví o tom, že Willy uvažuje o začlenění sady patchů umožňujících kompilaci 2.4 jader aktuálními kompilátory gcc 4.x. Nejde o triviální změny; gcc 4.x je dost odlišné na to, aby bylo potřeba množství oprav širokého dosahu. U řady 2.6 také nebyl přechod na gcc 4.x záležitostí na pár hodin.

Nasnadě je otázka, proč by někdo, kdo nemá zájem o provoz aktuálního jádra, chtěl používat aktuální kompilátory. Jednu odpověď lze nalézt v samotném oznámení: někteří administrátoři nasazují jádra 2.4 na ultrastabilních systémech, ale kompilují je na svých desktopech. Je čím dál těžší najít aktuální distribuci s tak starým kompilátorem, aby s ním šla kompilovat jádra 2.4, takže mají tito administrátoři potíže. Jádro řady 2.4, které by mohlo být zkompilované aktuálním gcc, by umožnilo využít nové systémy ke kompilaci jader pro nasazení na stabilních produkčních systémech, z nichž mnohé ani nemají kompilátor nainstalovaný.

Alexander Peslyak poznamenal, že Openwall GNU/*/Linux plánuje upgrade na gcc 4.x, ale raději by se při tom vyhnul změně jádra na 2.6.

Zajímavé čtení je Willyho popis uživatelů jader 2.4. Podle jeho pohledu jsou hlavními uživateli ti, kteří připravují vysoce spolehlivé systémy. Tito lidé na to raději používají 2.4 jádra:

Prostě proto, že ze společné zkušenosti už víme, jak dlouho mohou tyto verze běžet bez restartu (ale u čerstvé nové verze, která za poslední tři měsíce vstřebala 5700 patchů, to nevíme), a protože když přidáme několik málo patchů, můžeme se spolehnout i na bezpečnost. Dokud se vás nové potíže netýkají nebo jste kryti dodatečnými opravami, je vyhráno. Je-li nutné aktualizovat za cenu dlouhého výpadku, zaplatíte za to.

Cílem je usnadnit těmto lidem práci - umožnit jim, kromě jiného, používat aktuální kompilátory, dokud nebude k dispozici 2.6 jádro, které by mohlo poskytnout stejnou záruku stability. Vývojový model řady 2.6 však poskytování takových záruk ztěžuje, protože starší 2.6 jádra přestávají být poměrně brzy spravována (i když distribuce by je mohly spravovat déle - a také to dělají). Bylo by obtížné nalézt 2.6 jádro, které je už několik let stabilní, bezpečné a kontinuálně spravované.

Willy doufá, že současné jádro 2.6.16, jehož dlouhodobé údržby se chopil Adrian Bunk, v tomto směru pomůže. Dostane-li se 2.6.16 jednoho nebo dvou let oprav (a ničeho jiného), mohlo by se přiblížit stavu, kdy by mu věřili lidi spravující vysoce spolehlivé systémy. Čas ukáže, jestli toto jádro dojde tak daleko.

Stojí za zmínku, že několik (OK, jen jeden) vývojářů vyjádřilo nesouhlas s dlouhodobým vývojovým modelem 2.6.16. Tento vývojář řekl, že by bylo lepší zvolit správce stabilního stromu prostřednictvím veřejného hlasování a dále pak přesunout vývoj do řady 2.7. Tato stížnost ignoruje skutečnost, že dobrovolníků pro dlouhodobé spravování 2.6 jader byl vždy nedostatek; vlastně to vypadá, že Adrian je jediný. Nezdá se, že by jmenování Adriana dlouhodobým správcem 2.6.16 někoho připravilo o životní sen. Takže je nepravděpodobné, že by se v budoucnu konaly jiné volby správců.

Kevents a nová API

Navrhované rozhraní kevent už se tu probíralo - vizte články Rozhraní pro jaderné události a The kevent interface. Kevents nabralo během posledních několika týdnů rychlost, až to vypadá, že by začlenění do 2.6.19 nemuselo být nemožné. Většině vývojářů, kteří kód kontrolovali, se hlavní myšlenka líbí (jednotné rozhraní, prostřednictvím kterého by mohly aplikace získávat informace o událostech, jež je zajímají) a jsou spokojeni i s implementací v jádře. Až teď se však dostává pozornosti uživatelskému API, které kevents doprovází. Definice API je však velmi důležitá. Tento text jej prozkoumá ze dvou perspektiv - technické a politické.

Diskuze o navrhovaném API byla poněkud zbržděna nedostatkem dokumentace - a skutečností, že se API neustále rychle mění. Ve snaze shromáždit dostupné informace založil Stephen Hemminger u OSDL stránku, kde je popsáno API systémového volání. Chybí tam však jeden z důležitých aspektů kevents: možnost přijímat události prostřednictvím sdíleného paměťového rozhraní. Tuto mezeru se pokusím zaplnit.

Jedním z cílů kevents je maximální možné zrychlení zpracovávání událostí - například aby se mohl vysoce výkonný síťový server prokousat obrovskými počty událostí za vteřinu bez znatelné systémové režie. Jedním ze způsobů, jak toho dosáhnout, je vyhnout se systémovým voláním, kdykoliv je to možné. Proto je zájem o mapování kevents přímo do uživatelského prostoru; tento přístup aplikaci umožní odebírání událostí bez nutnosti volat kvůli každé z nich jádro.

Aby mohla aplikace rozhraní mmap použít, obdrží jako obvykle popisovač souboru kevent. Prosté zavolání mmap() pak vytvoří sdílený buffer pro komunikaci. Velikost bufferu je v současné době určena parametrem uvnitř jádra - bude tam uložen maximální počet kevents. Pravděpodobně přibude ještě makro KEVENT_MMAP_PAGES (nebo něco na ten způsob), které za aplikaci určí, kolik stránek má namapovat.

S výsledným paměťovým polem pak jádro zachází jako s velkým kruhovým bufferem. Je tam však pouze jeden index - kam jádro zapíše následující událost. Jinými slovy, jádro netuší, které události už si aplikace přebrala; zpozdí-li se aplikace příliš, začne jádro přepisovat dosud nezpracované události. Možná proto je buffer docela velký - v současné verzi patche pojme 4096 událostí.

Události uložené v bufferu nejsou stejnými strukturami ukevent, jaké používá rozhraní systémového volání. Místo toho je tam zkrácená verze ve formě struct mukevent:

    struct kevent_id
    {
	union {
	    __u32 raw[2];
	    __u64 raw_u64 __attribute__((aligned(8)));
	};
    };

    struct mukevent
    {
	struct kevent_id	id;
	__u32			ret_flags;
    };

Pole id obsahuje informace o tom, co se stalo: například příslušný popisovač souboru. Vlastní kód události tam však není.

Nejedná se však o čistý kruhový buffer. Je formátován se čtyřbajtovým polem na začátku každé stránky, což je následováno tolika strukturami mukevent, kolik se jich do stránky vejde. Čtyřbajtové pole na první stránce obsahuje index aktuální události - kam jádro zapíše událost další. Aplikace si bude pravděpodobně pamatovat poslední událost, kterou z bufferu přečetla, přičemž bude posunovat počítadlo kupředu tak dlouho, dokud jádro nedožene. Je však nutné, aby si aplikace všimla každého překročení hranice stránky, aby mohla přeskočit počítací pole.

Protože neexistuje způsob, jak dát jádru najevo, že byly události z namapovaného paměťového kruhu zpracovány, a protože kruh o událostech neposkytuje plné informace, musí aplikace tak jako tak kvůli událostem volat jádro. Jinak by se tam hromadily, dokud by nebylo dosaženo maximálního počtu. Takže bude těžké se současným kódem využít výhodu přístupu založeného na mapované paměti. Jak však bylo zmíněno, je to velice mladé API, takže se dá předpokládat, že budou tyto malé problémy v budoucny vyřešeny.

Mezitím způsobilo kevents samostatnou diskuzi o tom, jak začleňovat nová API. Jistý Nicholas Miell požadoval, aby byla pro rozhraní sepsána nějaká dokumentace:

Je to někde zdokumentováno? Myslím, že každé nové uživatelské rozhraní by mělo mít manuálové stránky vysvětlující jeho využití a měl by být k dispozici nějaký vzorek kódu - předtím, než bude do jádra začleněno, aby se vyřešily případné problémy.

Odpovědí mu bylo: To myslíš vážně? Ostatní se shodovali v tom, že pokud pan Miell opravdu nějakou dokumentaci chce, měl by sednout a napsat ji. Je však třeba zmínit, že v průběhu diskuze se pan Miell choval způsobem, který mu s největší pravděpodobností nepomůže inspirovat někoho ke spolupráci. Zdá se, že dané rozhraní, proces vývoje a lidi v něm zapojené z nějakého důvodu nesnáší.

Je však také potřeba říct, že na jeho požadavku něco je. Vytváření uživatelských rozhraní se od psaní většiny jaderného kódu liší. Mnoho věcí vychází z evolučního charakteru jádra - nacházení lepších řešení problémů znamená kontinuální vývoj. Uživatelská rozhraní se však nemohou vyvíjet - jakmile jsou vydána jako součást hlavního jádra, je nutné je navždy spravovat ve stejné podobě. Musí být správně hned od počátku. Takže není přehnané očekávat, že úroveň kontroly nového uživatelského API bude vyšší, a že bude poskytnuta dokumentace k navrhovaným API, která by kontrolu usnadnila. Je však také pravda, že původní vývojář není pro takový úkol vždy ten nejlepší.

Jedna z otázek, která byla ve spojení s rozhraním položena, se týkala jeho podobnosti s mechanismem kqueue z FreeBSD. Účel rozhraní je stejný, ale nebyl učiněn žádný pokus o emulaci kqueue API. Andrew Morton napsal:

Pokud je kqueue bez chyb, tak bychom mohli ušetřit starosti vývojářům aplikací a přesně ho zkopírovat. Pokud kqueue _má_ chyby, pak bychom ty slabiny měli identifikovat a poučit se. Dělat něco, co vypadá stejně, funguje stejně, dělá totéž, ale má odlišné API, to nikomu neprospěje.

Zjevně existují závažné důvody, proč kqueue nekopírovat, ale zatím nebyly objasněny.

Kevents by mělo znamenat velké zlepšení pro autory linuxových aplikací. Nové API by mělo shromáždit všechny zajímavé informace na jediné místo, nabídnout výrazné zvýšení výkonu a usnadnit portování aplikací z jiných operačních systémů. Ale pokud má API naplnit velké naděje, které jsou do něj vkládány, bude potřeba podrobná kontrola od mnoha zainteresovaných stran. Ta kontrola už začíná, takže můžete čekat, že bude tohle nové API nějakou dobu v centru pozornosti.

       

Komentáře

[newman]

maly preklep:

s/objesněny/objasněny/

[camlost]

další:

"Je-li nutné aktualizovat za cenu dlouhého výpadku, zaplatíte na to."

[Robert Krátký]

Dík, opraveno.

[Bubak]

A jeste jeden preklep: WT prevzal udrzbu 2.4 po 2.4.33 (mas 2.4.23).

[Robert Krátký]

Nějak se to rojí...

[deda.jabko]

Ostatní se shodovali v tom, že pokud pan Miell opravdu nějakou dokumentaci chce, měl by sednout a napsat ji.

Tento pristup me nedavno vcelku vytocil... hledal jsem dokumentaci k futexum, nasel jsem asi tri verze... a nakonec bylo nejlepsi vzit si zdrojaky.

kazdopadne pristupovat takto k dokumentaci neni moc dobra cesta..

[Pavel Janousek]

A kde je citat tydne? Ja se na nej tak tesil...

[Láďa]

Jelikož jádro 2.6.16 je aktuální verze pro Hardened project v Gentoo, tak mi snaha o dlouhodou údržbu přijde jako dobrý nápad