Jaderné noviny – 14. 7. 2011: Jak vyřešit nepořádek v logu jádra

26. 7. 2011 | Jirka Bourek

Články - Jaderné noviny – 14. 7. 2011: Jak vyřešit nepořádek v logu jádra  

Aktuální verze jádra: 3.0-rc7. Citáty týdne: Andrew Morton, Linus Torvalds. Jak se to jádro bude jmenovat?. Problémy se strukturovanými logy.

Obsah

• Aktuální verze jádra: 3.0-rc7
• Citáty týdne: Andrew Morton, Linus Torvalds
• Jak se to jádro bude jmenovat?
• Problémy se strukturovanými logy

Aktuální verze jádra: 3.0-rc7

Současné vývojové jádro je 3.0-rc7 vydané 11. července. Myslím, že jsem říkal, že -rc6 by mohlo být poslední. Lhal jsem. Věci byly poměrně klidné, ale je tu dost nových záležitostí, takže jsem chtěl vydat další -rc; stále také máme nějaké problémy se změnami RCU, které působí potíže, když k RCU událostem dojde před kompletní inicializací plánovače. Takže -rc7 je venku. Všechny detaily vizte v kompletním changelogu.

Stabilní aktualizace: stabilní aktualizace 2.6.32.43 a 2.6.33.16 vyšly 13. července; 8. července vyšlo 2.6.39.3. Všechna jádra obsahují obvyklý seznam oprav – v případě 2.6.39.3 je jich poměrně hodně.

Citáty týdne: Andrew Morton, Linus Torvalds

Changelog nám zapomněl sdělit, jaké jsou dopady této chyby viditelné pro uživatele. To od něj bylo opravdu špatné. Ošklivý changelog. Nedostaneš kostičku.

-- Andrew Morton

Právníci: vypadají jako rozumní a chytří lidé, když na ně koukáte jako na jednotlivce. A stejně se pokusí dohadovat se, jestli si pamatujete specifické datum příspěvku do newsgroup, který jste napsali. Co na tom, že ten příspěvek u sebe má jasně napsané datum a je odpovědí na jiné příspěvky (a je na něj odpovídáno jinými příspěvky), které také mají datum.

-- Linus Torvalds

Jak se to jádro bude jmenovat?

Když Linus na konci května oznámil jádro 3.0-rc1, stále se identifikovalo jako „3.0.0“. Očekávalo se, že mnoho skriptů předpokládá, že třetí číslo existuje a Linus je nechtěl rozbít hned zezačátku. I tak ale doufal, že poslední „.0“ zmizí:

Máme před sebou obvyklých 6-7 týdnů zápasu, než ho vydáme a než se skripty pročistí, takže finální verze by měla být jenom „3.0“. Tým pro stabilní jádra může třetí číslo použít pro své verze.

Rychle vpřed k 3.0-rc7 a jádro se pořád identifikuje jako 3.0.0. I když jednoznačné informace chybí, zdá se, že je stále mnoho programů a skriptů, které bez posledního čísla přestanou fungovat. V jistém smyslu se schéma s třemi čísly ve verzi stalo během let součástí jaderného ABI. Dalo by se dohadovat, že všechno, co přestane fungovat, bylo napsáno hloupě, ale i tak je cílem vyhnout se rozbíjení programů v uživatelském prostoru. Takže i když není žádná jednoznačná odpověď, zdá se, že vydání z hlavní řady budou ještě nějakou dobu mít tři čísla. Bylo by nicméně velice překvapivé, kdyby první stabilní aktualizace měla jiné číslo než 3.0.1.

Je zde nicméně další otázka: co s programy, které se nedokáží vyrovnat s jiným číslem verze než „2.6.x“? Takové zjevně existují. Prohlásit, že verze jádra budou navždy začínat „2.6“ jde za hranice i té největší snahy dodržet binární kompatibilitu; na něco takového nedojde. Aby zjednodušil život lidem, kteří takové programy mají, implementoval Andi Kleen nový režim [personality], který předstírá, že ke změně na 3.0 nikdy nedošlo. Pokud je program spuštěn v tomto režimu, bude si myslet, že verze jádra je 2.6.40; 3.1 bude vypadat jako 2.6.41 atd.

Andi říká: Vím, že je to poněkud ošklivé, ale lepší workaround jsem nevymyslel a kompatibilita pro existující programy je důležitá. V době psaní tohoto článku se daný patch nicméně ještě nedostal do hlavní řady.

Problémy se strukturovanými logy

napsal Jonathan Corbet, 12. července 2011

Debata o konceptu jmen disků přívětivých pro uživatele byla tento týden znovu rozdmýchána, když Nao Nishijima zaslal novou verzi patche pro trvalá jména zařízení. Neshody o této vlastnosti trvají; je ale možné bude začleněna i tak. Jádrem diskuze nicméně byl koncept, který jde ještě dál za přidání uživatelem specifikovaných jmen ke specifickým zařízením; je to větší problém, jak dostat z jádra strukturovaná data.

Po všech těch letech je hlavním mechanismem, jak jádro předává informace do uživatelského prostoru, primitivní funkce printk(). Není třeba říkat, že je to užitečná a flexibilní cesta, jak dostat zprávy mimo jádro, ale neklade žádné požadavky na strukturu těchto zpráv. To vše vede k různým výstupům jako (z drivers/net/de620.c):

printk(KERN_WARNING „%s: Thanks, I feel much better now!\n“, dev->name);

nebo slavné zprávy z drivers/char/lp.c:

printk(KERN_INFO „lp%d on fire\n“, minor);

Nelze vinit správce systémů z toho, že nemají tušení, jak na takové zprávy mají reagovat.

Došlo ke změnám, které měly vynutit nějakou strukturu výstupu printk(), počínaje přidáním značky identifikující závažnost každé zprávy. I tak ale není těžké najít volání printk() bez identifikace závažnosti; skutečné vynucení jejich používání se ukázalo jako příliš těžké. Nějakou strukturu přidává dev_printk() (a varianty jako dev_err()), ale používání těchto funkcí rozhodně není všeobecné.

Chybějící struktura znamená, že zprávy nejsou příliš konzistentní; každé dva síťové ovladače téměř určitě vypíšou jinou věc popisující stejnou situaci. Jaderné zprávy se také mohou postupem času změnit; zprávy vypisované pomocí printk() se normálně nepovažují za součást jaderného ABI i přes fakt, že jejich změny mohou rozbít skripty, které se ze systémových logů pokouší vytáhnout užitečné informace. Není překvapivé, že téměř před rokem Andrew Morton řekl:

Celý přístup jádra k zasílání zpráv je poměrně nahodilý a neschopný a smutný. Objevilo se několik návrhů, jak ho zlepšit a racionálně rozdělit věci do kategorií tak, aby to bylo pro obsluhu užitečnější, ale zdá se, že se nikdy nic nedostane do hlavní řady.

Různí lidé se situaci na některých místech pokoušeli vylepšit; uživatelsky přívětivá jména disků, která se snaží zařízením přiřadit konzistentní jména, jsou jeden takový pokus. Patch netoops od Google je další; pomáhá Googlu zjistit, které stroje padají bez toho, aby jejich správci museli přehrabovat logy. Tyto změny ale mají daleko k obecnému frameworku pro strukturovaná data od jádra.

Během let došlo k několika pokusům takový framework vytvořit; ani jednomu se nepodařilo do jádra dostat. Není těžké přijít na věrohodné zdůvodnění tohoto selhání. Množství práce, kterou to vyžaduje, je obrovské, obzvláště pokud někdo chce dodat strukturu do větší části zajímavých sdělení od jádra. Vývojáři mají printk() rádi; těžko je okouzlí jiné rozhraní, které k použití vyžaduje práci navíc, jeho výstup je (z principu) méně flexibilní a navíc může existovat společně se stávajícím logováním pomocí printk(). Vymyslet strukturovaný formát, který splní požadavky všech – a který nebude v následujících letech nutné doplnit formátem „verze 2“ – je výzvou samo o sobě.

Také je potřeba říci, že jaderní vývojáři jako celek vidí jenom malou hodnotu ve strukturovaných logovacích informacích. Nepomůže jim to ladit jejich jádra. Fakt, že mnoho uživatelů by takovou vlastnost chtělo, není pro vývojovou komunitu nerelevantní, ale zkušenosti ukazují, že o co vývojáři nemají zájem, je mnohem těžší začlenit – obzvláště když taková změna bude mít široký záběr a bude rušivá.

Pokud tento problém má někdy být vyřešen, zdá se, že je potřeba najít dvě věci: mechanismus, který bude vypadat, že by mohl fungovat, a motivaci pro jaderné vývojáře ho přijmout. Motivaci lze pravděpodobně najít v kombinaci (1) jejich výplatní pásky, protože zákazníci tuto vlastnost stále vyžadují, a (2) vyhlídky na neustávající proud ad hoc patchů, které budou přidávat strukturu do různých koutů jádra bez řešení skutečného problému. To ale stále ponechává otevřený problém, jak najít fungující řešení.

Autor tohoto článku nad touto záležitostí trochu přemýšlel a uvědomil si, že jádro již má hezký mechanismus, jak do uživatelského prostoru předávat strukturovaná data. Téměř na každém současném systému je adresář /dev spravován démonem udev; udev funguje tak, že od jádra přijímá vysoce strukturované zprávy, které popisují příchody a odchody zařízení, změny jejich konfigurace, požadavky na nahrání firmwaru a další. Je to zavedený protokol, který umožňuje sofistikované reakce na události v jádře. Udev a s ním spojený mechanismus „uevent“ si prošel porodními bolestmi, ale kód je nyní stabilní, funkční a používá se téměř univerzálně. Je možná načase, aby převzal další povinnosti.

Uevent rozhraní funguje, protože formát zpráv je jak strukturovaný, tak flexibilní; lze ho rozšířit, když je to potřeba. Generování událostí je téměř zcela zajišťováno automaticky v centrálním kódu pro ovladače; většina autorů ovladačů nemusí udělat vůbec nic, aby se události vygenerovaly a dokonce ani nemusí vědět, že pod kapotou tento mechanismus pracuje. Autoři ovladačů nemusí vytvářet své události; a museli by se hodně snažit, kdyby chtěli v jejich generování zabránit.

Logování jiných typů událostí bude pravděpodobně vyžadovat explicitní podporu v relevantním jaderném kódu; tato část vyžaduje zamyšlení. Vytvořit uevent ručně je poměrně náročná činnost; relevantní kód vypadá nějak takto:

retval = add_uevent_var(env, „ACTION=%s“, action_string);
if (retval)
        goto exit;
retval = add_uevent_var(env, „DEVPATH=%s“, devpath);
if (retval)
        goto exit;
retval = add_uevent_var(env, „SUBSYSTEM=%s“, subsystem);
if (retval)
        goto exit;

Je zjevné, že jakýkoliv pokus vložit takový kód na každé místo, odkud se něco loguje, nedojde nijak daleko. Co je potřeba, je rozumná sada pomocných funkcí. Tyto funkce, aby byly co nejužitečnější, by pravděpodobně byly poměrně těsně spojeny se subsystémy pod sebou. Ovladače pro úložná zařízení by měly funkce pro hlášení chybných bloků, změn zařízení, změn vícecestné konektivity. Síťové ovladače by potřebovaly hlásit události jako ztrátu nosné, nadměrný počet chyb při počítání kontrolních součtů či duplicitní MAC adresy. Veškerý jaderný kód by mohl benefitovat z pomocných funkcí logujících selhání alokace nebo nesplnění nějakých předpokladů [failed assertions]. V každém případě by pomocná funkce standardizovala formát hlášené informace a zároveň umožnila přidat dodatečné informace specifické pro místo, odkud se volá.

Přidání nové sady logujících funkcí by nutně vyžadovalo změny ovladačů tak, aby se dané funkce začaly používat. Zabralo by tedy čas dosáhnout něčeho, co by se alespoň trochu blížilo všeobecnému pokrytí, a ke 100% pokrytí by nedošlo nikdy. Na druhou stranu nemáme ani 100% pokrytí značkami KERN_* označujícími závažnost hlášení. Pokud toto rozhraní bude užitečné, lze si představit, že kódové cesty, které zajímají zákazníky podnikových distribucí, budou pokryty relativně rychle.

Na druhou stranu tento nápad má pravděpodobně několik aspektů, které jsou naprosto chybné; problém se strukturovaným logováním zůstane pravděpodobně nevyřešen ještě nějakou dobu. Avšak nezmizí; naopak, potřeba rozpoznat a automaticky reagovat na události systému jenom vzroste. Jednoho dne někdo přijde s řešením, které bude fungovat a které bude možné přijmout s minimálními potížemi; do té doby máme jenom printk().