Jaderné noviny – 30. 9. 2010: Jak udržovat stabilní jádro

18. 10. 2010 | Jirka Bourek | Jaderné noviny | 3829×

Citáty týdne: Ted Ts'o. Správa stabilního stromu na nestabilních základech. Organizování jaderných zpráv. Popisovače souborů jmenného prostoru.

Obsah

• Aktuální verze jádra: 2.6.36-rc6
• Citáty týdne: Ted Ts'o
• Správa stabilního stromu na nestabilních základech
• Organizování jaderných zpráv
• Popisovače souborů jmenného prostoru

Aktuální verze jádra: 2.6.36-rc6

Současné vývojové jádro je 2.6.36-rc6, které bylo vydáno 28. září. Není tu nic, co bych považoval za výrazněji zajímavé. Rád bych, aby se vývojáři podívali na Rafaelův nejnovější seznam regresí (předmět zprávy na lkml a v dalších mailových konferencích je „2.6.36-rc5-git7: Reported regressions from 2.6.35“), protože je vcelku krátký. Z nějakého důvodu nemám ten „příjemný a hebký“ pocit, možná protože je v těchto -rc pořád víc commitů, než bych v tomto okamžiku chtěl (a ne, ten den navíc není dost na to, aby to nárůst vysvětlilo). Zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu.

Stabilní aktualizace: 27. září byly vydány aktualizace 2.6.32.23, 2.6.35.6. Oprava překlepu, který působil problémy jenom lidem, kteří používají Xen, vynutila vydání 2.6.35.7, k čemuž došlo 29. září přímo na pódiu na LinuxCon v Japonsku.

Citáty týdne: Ted Ts'o

Tak se mi zdá, že ve FAQ pro nováčky mělo být varování, že výstupy různých skriptů jako je checkpatch a get_maintainer nejsou autoritativní a že jsou to heuristiky, které mají být doplněny lidskou inteligencí.

-- Ted Ts'o

Správa stabilního stromu na nestabilních základech

napsal Jonathan Corbet, 29. září 2010

Greg Kroah-Hartman zahájil svou úvodní přednášku na LinuxCon 2010 v Japonsku prohlášením, že nejzábavnější na vývoji Linuxu je to, že není stabilní; ve skutečnosti je to nejrychleji se pohybující softwarový projekt v historii lidstva. Toto tvrzení bylo podpořeno mnoha statistikami rychlosti vývoje, které čtenáři Jaderných novin dobře znají. Ve shrnutí jádro minulý rok absorbovalo každou hodinu 5.5 změn. Pak si Greg položil otázku, jak se může někdo snažit vybudovat stabilní jádro nad takto rychle se měnící základnou?

Odpověď začala hodinou dějepisu. Před patnácti lety vyšlo jádro 2.0.0 a věci vypadaly dobře. Měli jsme dobrou výkonnost, podporu SMP, krásného nového maskota a další. Po čtyřech měsících stabilizační práce vznikl strom 2.1.0 a vývoj hlavní řady pokračoval. Byly to samozřejmě ty dny tradičního vývojového cyklu sudé/liché, který tenkrát vypadal jako správný způsob, jak vyvíjet jádro.

Trvalo 848 dní a 141 vývojových verzí, než se dosáhlo jádra 2.2.0. Mnoho lidí mělo pocit, že by věci měly fungovat rychleji, takže když o čtyři měsíce později vyšlo jádro 2.3.0, doufalo se, že tento vývojový cyklus bude o něco kratší. V určitém rozsahu se to podařilo: trvalo jenom 604 dní a 58 verzí, než jsme se dostali k 2.4.0. Nicméně lidé, kteří se tenkrát Linuxem zabývali, si určitě pamatují, že u 2.4 opravdu dlouho trvala stabilizace; bylo to celých deset měsíců, než Linus měl pocit, že je čas vytvořit větev 2.5 a znovu přejít k vývoji.

Tentokrát vývojáři měli v úmyslu vývojový cyklus zkrátit opravdu, byla tu spousta kódu, který chtěli dostat k uživatelům co nejrychleji. Ve skutečnosti byl tlak na to dostat k uživatelům nové vlastnosti tak velký, že distributoři vkládali významné množství sil k backportování kódu 2.5 do jader 2.4, která dodávali. Výsledkem byl „bordel“ na všech úrovních: dodávaná jádra 2.4 byla nestabilní směskou patchů a vývojáři práci dělali dvakrát: jednou do 2.5 a podruhé pro backportování. Nefungovalo to moc dobře.

Výsledkem je, že vývojový cyklus 2.5 trval 1057 dní a obsahoval 86 verzí. V mnoha ohledech to bylo problematické, ale konečný výsledek – jádro 2.6 – byl mnohem lepší než 2.4. Během tohoto vývojového cyklu se stalo mnoho věcí; komunita se naučila, jak je potřeba jádro vyvíjet. Příchod BitKeeperu výrazně zlepšil distribuovaný vývoj a zdůraznil to, jak je důležité změny dělit na malé, revidovatelné a odladitelné části. Jaderná komunita, která existovala při vydání 2.6.0, byla chytřejší a zkušenější, než jaká kdy dříve byla; zjistili jsme, jak dělat věci lépe.

Tento vývoj vedl k přijetí „nového“ modelu vývoje hned v prvních dnech 2.6. Oddělené vývojové a stabilní větve zmizely a byly nahrazeny jediným, rychle se pohybujícím stromem, který vydává nové verze každé přibližně tři měsíce. Systém fungoval dobře, co se vývoje týče; stále se po několika letech používá. Trochu ale ztížil život distributorům a uživatelům. I tři měsíce mohou být, co se čekání na důležitou opravu týče, poměrně dlouhá doba. A když navíc tyto opravy přijdou s další várkou chyb, nemusí to být úplně vítané. Bylo tedy jasné, že je potřeba mít mechanismus, kterým se k uživatelům budou rychleji distribuovat opravy (a jenom opravy).

Tato diskuze vedla ke známému mailu od Linuse, ve kterém tvrdil, že nebude možné najít někoho, kdo bude udržovat stabilní jádro po jakkoliv dlouhou dobu. I tak ale nadhodil několik rad, se kterými by vhodný „chudák“ mohl takový strom vytvořit. Během několika minut Greg zvedl ruku a přihlásil se jako ten potenciální chudák; Chris Wright následoval. Greg v této práci pokračuje dál; Chris vytvořil cca 50 stabilních verzí a pak se vrátil zpět ke „skutečné práci“ a práci na stabilních jádrech opustil.

Stabilní strom od té doby funguje stále. Model se od počátku trochu změnil; jakmile je vydána verze hlavní řady, stabilní aktualizace se do ní dodávají přinejmenším po jeden vývojový cyklus. U většiny jader tyto aktualizace po prvním cyklu končí, což je důležitá součást toho, jak stabilní strom funguje; stanovuje to horní hranici počtu stromů, které je potřeba udržovat, a podporuje to uživatele v tom, aby se drželi aktuálnějších jader.

Greg prezentoval pravidla, která platí pro příspěvky do stabilního stromu: musí opravovat skutečné chyby, musí být malé, snadno ověřitelné atd. Nejdůležitější pravidlo je nicméně to, které říká, že se patch musí před přijetím do stabilního stromu objevit také v hlavní řadě. To zajišťuje, že se důležité opravy dostanou do obou stromů; také je díky tomu jistější, že oprava byla dostatečně revidována.

Některá jádra mají delší stabilní podporu než jiná; jedním příkladem je 2.6.32. Několik správců distribučních jader v době, kdy bylo aktuální 2.6.30, přemýšlelo, jestli by se všichni mohli shodnout na jednom jádře, které by se udržovalo delší dobu; shodli se na 2.6.32. Od té doby bylo toto jádro zahrnuto v SLES11 SP1, RHEL6, Debianu Squeeze, Ubuntu 10.04 LTS a v nedávno oznámené aktualizaci podnikového jádra od Oracle. Zatím se do něj dostalo 2000 oprav, přičemž přispívali všichni. 2.6.32 je velký příklad mezidistribuční spolupráce. Také je výsledkem všech těchto oprav velmi kvalitní jádro.

Greg upozornil na jednu zajímavou věc týkající se 2.6.32: dvě podnikové distribuce (SLES a nabídka od Oracle) aktualizovaly na tuto verzi v existující distribuci. To je nemalá změna v oblasti, kde se distributoři typicky drží původní verze jádra po celou dobu života distribuce. Držet se prastarého jádra má nicméně velké náklady, takže by bylo povzbuzující, kdyby tito distributoři zjistili, jak přejít na novější stabilní jádro bez problémů pro uživatele.

Proces práce se stabilním jádrem obecně funguje dobře a správci čím dál lépe pracují na zasílání důležitých oprav. Někteří správci jsou obzvlášť dobří a mají v repozitářích dedikované větve pro patche pro stabilní jádra. Ostatní... nejsou tak dobří; správci SCSI Jamesovi Bottomleymu bylo poměrně nejaponským způsobem řečeno, že on a jeho vývojáři by na tom mohli být lépe.

Lidé, které zajímají chystaná vydání stabilních jader, se mohou zúčastnit cyklu revidování. Dva až tři dny před každým vydáním Greg zasílá všechny kandidující patche do konference k revizím. Někteří lidé si stěžují na velký počet příspěvků, ale Greg je ignoruje: komunita kolem Linuxu vyvíjí veřejně. Za poslední dobu je čím dál tím více lidí, kteří mají zájem pomoci s tímto testováním před vydáním, což Greg považuje za „úžasné“.

Přednáška končila praktickou ukázkou: Greg zabalil a vydal 2.6.35.7 (kódové jméno „Yokohama“) přímo během přednášky. Zdá se, že aktualizace 2.6.35.6 – evidentně vydaná během přednášky Dirka Hohndela o MeeGo o pár dní dříve – obsahovala překlep, který ztěžoval život uživatelům Xenu. Oprava je pravděpodobně první verzí jádra, které bylo vydáno před obecenstvem; doufejme, že se v ní neobjeví podobný problém.

Organizování jaderných zpráv

napsal Jonathan Corbet, 29. září 2010

Ve svém předchozím životě autor tohoto článku vyvíjel ve Fortranu na systému VAX/VMS. Každá zpráva, kterou VMS vypsal, byla ozdobena unikátním identifikátorem, který šlo najít ve velké modré knize společně s několika odstavci (snad) užitečného textu o tom, co ta zpráva skutečně znamenala. Linux žádný obdobný mechanismus nemá, ale to rozhodně není kvůli chybějící snaze. Přednáška na LinuxCon Japan rozebírala nový přístup k organizaci jaderných zpráv, který má – jak alespoň doufá jeho autor – lepší šance dostat se do hlavní řady.

Andrew Morton nedávno popsal jaderný přístup ke zprávám takto:

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 užitečnější obsluze, ale přes hranici se podle všeho nedostane nic.

Hisashi Hashimoto popsal snahu, která se, jak doufá, přes hranici dostane. Za tímto účelem on i další prozkoumali předchozí pokusy přinést do jaderných zpráv pořádek. To je neodradilo, takže začali pracovat na novém projektu; pak představil Kazua Ita, který popsal jejich práci.

Pokusy přivést do jaderných zpráv nějaký řád obvykle zahrnují buď připojení identifikátoru ke zprávě nebo nějakou standardizaci formátu zprávy. Jedna z věcí, kterou Ito-san řekl hned na začátku, byla, že jakékoliv schéma vyžadující změny všech řádek s printk() se pravděpodobně nedostane příliš daleko. V jádře je takových řádek přes 75 000, mnoho z nich je pohřbeno v makrech; není žádný praktický způsob, jak je změnit všechny. Další obalovací funkce, jako je například dev_printk(), věci ještě více komplikují. Jakoukoliv změnu je tedy potřeba provést tak, aby fungovala s existujícími voláními printk().

Bylo zváženo několik přístupů. Jeden by vytvořil sadu obalovacích maker, která by zformátovala identifikátory zprávy a předala je printk(); nevýhodou této metody je pochopitelně to, že to stále vyžaduje změnu všech volání printk(). Také je možné změnit printk() na makro, které by sestavilo identifikátor zprávy z dostupných informací o jméně souboru a číslu řádky; tyto identifikátory by nicméně byly příliš nestálé. Přístup, který vývojáři zvolili, se tedy zaháčkovává do samotné printk() a identifikátory ke zprávám přidává, když se vypisují do konzole a logů.

Tyto identifikátory zpráv (také nazvané "pomocné tokeny pro lokalizaci zpráv" [message-locating helper tokens]), musí být přiřazovány automaticky; žádat komunitu vývojářů, aby udržovali seznam identifikátorů a přidávali je ke zprávám, se zdá být jistou cestou ke zklamání. Okamžitě se tedy musíme zamyslet nad tím, jak budou tyto identifikátory generovány; hlavními kritérii zde je unikátnost a stabilita. Ukazuje se, že Ito-sana absolutní unikátnost nezajímá; jestliže příležitostně jedna nebo dvě zprávy budou mít stejný identifikátor, správce by stejně měl být snadno schopen najít tu správnou bez velkých potíží.

Stabilita je ale důležitá; jestliže se identifikátory zpráv budou často měnit mezi vydáními – nebo dokonce mezi booty – ubere jim to na hodnotě. Z toho důvodu není generování zpráv při kompilaci pomocí proměnných preprocesoru jako __FILE__ či __LINE__ dostatečné, přestože je to jednoduché. Také by šlo použít virtuální adresu místa, ze kterého se volá printk() - u té je garantováno že bude unikátní, ale může se změnit mezi booty, protože závisí na věcech jako je pořadí nahrávání modulů. Je potřeba najít jiný přístup.

Skupina se shodla na generování CRC32 hashe formátu zprávy za běhu. Tento přístup trochu zvyšuje náklady pro běh, čemuž by bylo hezké se vyhnout, ale tyto náklady nejsou tak vysoké a jestliže je úzkým hrdlem pro výkonnost systému volání printk(), problém je někde jinde. Když bude systém nakonfigurován, aby vypisoval identifikátory zprávy, hodnota hashe bude při vypisování přidána před zprávu (s formátem "(%08x):"). U CRC32 hashe není garantováno, že identifikátor bude pro každou zprávu unikátní (i když je to lepší než CRC16, u kterého je garantováno, že bude kolidovat se 75 000 zprávami), ale bude tomu dost blízko.

Diskuze o současné implementaci během přednášky ukázala, že zbývají problémy k vyřešení. Zprávy vypsané pomocí dev_printk() budou mít vždycky stejný identifikátor, což není žádoucí výsledek. Nově přidaná direktiva "%pV" pro formát (která indikuje předání struktury obsahují nový formátovací řetězec a seznam parametrů) věci také významně komplikuje, protože přidává rekurzivní zpracování zpráv. Implementace tedy bude ještě vyžadovat další práci, ale k základní implementaci moc nesouhlasných názorů nepadlo.

Až na konci přednášky se diskutovalo o tom, v jakých případech by bylo možné tuto vlastnost použít. Původním cílem je jednoduše zjednodušit nalezení místa v jaderném kódu, ze kterého zpráva pochází &ndash+ používání maker, pomocných funkcí atd. může značně ztížit dohledání zprávy jednoduchou operací grep. S ID zprávy a podpůrnou databází (která by se udržovala pomocí nástroje v uživatelském prostoru) by vývojáři mohli jít přímo ke správnému volání printk(). Vinod Kutty poznamenal, že u velkých systémů by automatické monitorovací systémy mohly identifikátory použít k rozeznání situací, které vyžadují nějakou reakci. Dlouhodobým cílem je také vytvoření databází zpráv přeložených do jiných jazyků, a pomocných informací pro specifické zprávy.

Pro tuto práci tedy existuje skutečná motivace. Jak ale bylo zmíněno na začátku, vyhlídky na to dostat jakýkoliv patch identifikace zpráv přes proces začleňování byly zatím vždy neveselé. Doufá se, že tentokrát bude řešení dostatečně užitečné (i jaderným vývojářům) a nerušivé na to, aby se dostalo do hlavní řady. To zjistíme brzy; jakmile bude patch opraven, bude zaslán ke komentářům do mailové konference.

Popisovače souborů jmenného prostoru

napsal Jake Edge, 29. září 2010

Přidělit skupině procesů jejich vlastní pohled na globální prostředky jádra – například na síťové prostředí a stromy souborového systémů – je jedním z cílů vývojářů kontejnerů v jádře. Tyto pohledy či jmenné prostory jsou vytvořeny při clone() jedním z příznaků CLONE_NEW* a jsou viditelné pouze pro nový proces a jeho potomky. Eric Biederman navrhl mechanismus, který by jiným procesům mimo potomky tvůrce umožnil vidět jmenné prostory a přistupovat k nim.

Když jsme se v březnu dívali na dřívější verzi, Eric navrhoval dvě nová systémová volání – nsfd() a setns(). Od té doby volání nsfd() zrušil a přidal nový adresář /proc/<pid>/ns se soubory, které lze otevřít a které poskytnou popisovače pro různé jmenné prostory. To odstraňuje nutnost mít samostatné systémové volání.

V současnosti musí ve jmenném prostoru běžet proces, aby tento jmenný prostor nebyl zrušen, ale jsou také případy, kdy je poměrně těžkopádné mít dedikovaný proces, který bude udržovat jmenný prostor naživu. S novými patchi vázané připojení souboru v proc:

mount --bind /proc/self/ns/net /some/path

udrží jmenný prostor naživu do doby, než bude soubor odpojen.

Od dřívějšího návrhu se volání setns() nezměnilo:

int setns(unsigned int nstype, int nsfd);

Volání nastaví jmenný prostor procesu na ten, který označuje předaný popisovač souboru nsfd, který by měl být odkazem na otevřený jmenný prostor v /proc. nstype je buď nula nebo typ jmenného prostoru, do kterého se volající pokouší přepnout (implementovány jsou "net", "ipc, "uts" a "mnt"), takže volání selže, pokud typ neodpovídá jmennému prostoru označenému pomocí nsfd. Volání také selže, pokud volající nemá kvalifikaci CAP_SYS_ADMIN (v podstatě práva superuživatele).

V tomto kole Eric také přidal funkci pro pohodlí v podobě systémového volání socketat():

int socketat(int nsfd, int family, int type, int protocol);

Volání odpovídá socket(), ale navíc přijímá parametr nsfd, který označuje jmenný prostor, ve kterém má být socket vytvořen. Jak bylo poukázáno v diskuzi k patchi, socketat() by bylo možné implementovat pomocí setns():

setns(0, nsfd);
sock = socket(...);
setns(0, original_nsfd);

Eric souhlasí, že by bylo možné to udělat v uživatelském prostoru, ale má obavy ze souběhů v takové implementaci. Pro síťové jmenné prostory má navíc na rozdíl od ostatních na mysli specifické případy použití:

Použitelné je to pro těch pár síťových aplikací, u kterých dává smysl naslouchat na socketech v několika jmenných prostorech naráz. Například to může být domácí počítač, který je pomocí VPN připojený do sítě v práci a VPN běží v jiném jmenném prostoru, abyste nemuseli mít obavy z konfliktů adres mezi sítěmi a náhodného bridgování mezi nimi a abyste mohli pro různé sítě používat různé resolvery.

Také si ale uvědomil, že by to mohlo být poněkud kontroverzní. Na linux-kernel se o patchích příliš nediskutovalo a Eric řekl, že v mailové konferenci kontejnerů obdržel kladná hodnocení. Patche zaslal, aby mohli další vývojáři revidovat přídavky do ABI, a nezdá se, že by k setns() ani ke změnám v /proc byly nějaké námitky.

Změny ve jmenném prostoru „pid“ nebyly v patchích zahrnuty, protože je nejprve potřeba nějakých úprav, aby tento jmenný prostor bylo možné bezpečně odsdílet. Tyto úpravy nicméně nepostihují ABI, takže jakmile bude přidán jmenný prostor pid, zdá se pravděpodobné, že brzy uvidíme návrat těchto patchů možná bez socketat(). Umožnit dostatečně privilegovanému procesu přistupovat k jiným jmenným prostorům bude užitečným přídavkem a nemusíme k tomu mít tak daleko.

       

Komentáře

[Marián Kyral]

Díky, pěkné počtení.

[Mykonou]

Taky se pripojim k podekovani, fajn cteni.

[PetrHL]

Diky za skvely preklad. V originale bych to nedal.

[j3nda]

+1 taky si rad pockam na cs verzi. v en bych to urcite nedal. diky. j3.

[Jirka]

Tak nevim, jestli ten hash u zprav neco resi. Jestli tomu dobre rozumim, tak by stacilo udrzovat tu databazi hlasek. Bylo by to prakticky totez, jako udrzovani databaze hashu.

Nevim, jak je to v jadre presne zarizeno, ale co kdyz je ten ten retezec predavany funkci printk generovany za behu? To preci hash a potazmo ani zadna jina databaze techto retezcu moc nepomuze, ne?

Jestli by nakonec nebylo lepsi zmenit tech 75000 volani printk.

[cronin]

Tych volani je vela; zmenit ich vsetky by trvalo roky, zdokumentovanych by aj tak 95% nikdy nebolo. Problemom su hlasky v makrach a funkciach, ktore sa volaju z roznych miest. Hlasky su tak nejednoznacne, co sa tych ich "povodcu".

Hash sa negeneruje z hlasky samotnej, ale z formatovacieho retazca, ktory je staticky.

Zmenit tych 75000? Super, do toho, ides!

[dgagag]

ed a sed to imho riesi...

[jos]

ty seš ňákej chytrej, kdyby to ed se sedem řešily* tak by to tak asi udělali

* nebo řešili? program bez programu jako hrad bez hradu ... hm stejně mi to s tim tvrdým nejde přes prsty

[Marián Kyral]

Tak si představ dva pány. Jeden se jmenuje ed a druhý sed Ale taky mi to tam moc nesedí. Kdyby tam bylo "dva programy rešily" tak to jo, ale když jsou vyjmenované, tak mi to nějak nepasuje.

[kralyk z abclinuxu]

* nebo řešili? program bez programu jako hrad bez hradu ... hm stejně mi to s tim tvrdým nejde přes prsty

Jde o životnost, ne o vzor. A životnost = (1. pád != 4. pád), psáno céčkově...

[nikdo]

No, moc céčkově to není. Céčkové identifikátory nemohou začínat číslicí.

Takže snad jedině životnost = (pád[0] != pád[3]);

[Michal Kubeček]

A on snad céčkový identifikátor může obsahovat "á"? Když si chce někdo hrát na hnidopicha, měl by si sám dávat pozor.