Portál AbcLinuxu, 20. dubna 2024 05:42
Aktuální verze jádra: 3.18. Citáty týdne. Začleňovací okno verze 3.18 – závěr. Tři přednášky o vývojových nástrojích jádra.
Aktuální vývojové jádro je 3.18-rc1, vydané 19. října (odkaz), trošku v předstihu oproti plánu. Linus řekl, že on bude nadmíru otevřený požadavkům na zařazení po rc1 od lidí, kteří „se trochu loudali.“ Linus k tomu řekl:
Existuje také alespoň jeden požadavek na zařazení, který doufám dostanu co nejdříve a který mám stále v plánu zařadit. Myslím tím, že stále doufám, že bude konečně začleněn overlayfs.
Nakonec si během tohoto začleňování našlo do hlavního repozitáře cestu 9 711 nezačleněných sad změn.
Stabilní aktualizace: minulý týden nebyly vydány žádné stabilní aktualizace.
Souhrn o začleňovacím okně z minulého týdne odvážně předpovídal, že začleňovací okno verze 3.18 by mohlo skončit dříve, než se očekávalo. A Linus opravdu vydal verzi 3.18-rc1 19. října, o týden dříve oproti původnímu plánu. Nakonec si před vydáním verze 3.18-rc1 našlo do Linusova úložiště cestu 9 711 nezačleněných sad změn; od té doby bylo přidáno dalších zhruba 200 (v době vzniku tohoto textu). Linus dal jasně najevo, že bude otevřenější než obvykle k přidáním funkcí po vydání rc1, vzhledem k tomu, že se někteří vývojáři mohli spoléhat na původní časový plán. Několika funkcím se to již podařilo.
Mezi začleněné změny z pohledu uživatele od shrnutí z minulého týdne patří:
V tomto okamžiku začíná být důležitý stabilizační proces. Pokud bude původní plán dodržen, finální verzi jádra 3.18 lze očekávat někdy kolem začátku prosince.
Konference linuxových instalatérů se snaží soustředit na diskuse nad prezentacemi. Mikrokonference o vývojových nástrojích se ale pustila proti proudu, protože se skládala převážně z řady prezentací o zajímavém zavádění nástrojů do jádra. Některé nástroje jsou užitečné dříve než ostatní; zde se zaměříme na několik nástrojů, které mohou pomoci vývojářům již nyní.
Projekt backportů jádra se zaměřuje na zpřístupnění ovladačů z nejnovějších verzí jádra do starších stabilních vydání jádra. Myšlenkou je poskytovat nejlepší hardwarovou podporu na platformě, která je jako celek poměrně stabilní a bez chyb. Není překvapením, že distributoři korporátních verzí Linuxu mají o tuto práci zájem, ale nejsou sami.
Projekt má v současné době tři hlavní vývojáře, kteří pracují na backportu asi 800 ovladačů starších jader. Dovedete si představit, že je to docela dost práce; Luis Rodriguez mluvil o tom, jak se dá nástroj Coccinelle použít k řešení problémů v rámci relativně malé skupiny vývojářů. (Seznámení s nástrojem Coccinelle a jeho schopnostmi viz tento článek).
Je zřejmé, že k rozšíření na zhruba 800 backportovaných ovladačů vyžaduje poměrně velkou míru kompromisů. Testování všech těchto ovladačů je jednou z prvních věcí; vývojáři nemají na testování dostatek času ani hardwaru. Takže můžou jen slíbit, že zkompilované backportované verze ovladačů budou fungovat. Radiče jsou backportované až ke stabilnímu jádru 3.0; skupina dříve nabízela backporty až do řady 2.6, ale zájem o ně téměř vymizel. Backportování mnoha typů ovladačů ani není v plánu; například subsystém DRM je komplexní a není dostatek zájmu na straně distributora, který by práce na backportu podnítil. Takže většina backportovaných ovladačů se zaměřuje na subsystémech jako Ethernet, bezdrátových připojení, Bluetooth, NFS, Video4Linux apod.
Luis řekl, že projekt backportování slouží jako motivace vývojářům, aby se jejich kód dostal do hlavní verze. Jakmile je ovladač v hlavní větvi jádra, backportování je k dispozici zdarma.
Backportování je trochu neobvyklé použití nástroje Coccinelle, který se běžně používá k vývoji jádra směrem vpřed. Většina vývojářů ji občas používá pro změny ve vymezených částech jádra směrem vpřed. Projekt backportování ho naopak používá k portování ovladačů v seznamu do starších verzí.
Backportování se podle Luise obvykle provádí rozprostíráním #ifdef po celém kódu. To je „backportování na prášky“; vede k opravám, které jsou rozsáhlé a náročné na revize. A stejné únavnou práci je nutné udělat pro každý ovladač na seznamu. Musí existovat lepší způsob.
Prvním krokem tímto směrem je přesunout co nejvíce kódu spojeného s backportování do souborů hlaviček. Pokud například dojde ke změně funkčního prototypu, příslušná hlavička bude obsahovat novou verzi funkce (pod jiným názvem), která funguje se starším kódem. Různá místa volání lze upravit pro použití nové funkce, bez řádků #ifdef v samotném kódu. Podle Lusie může jednodušší změny provést Coccinelle zcela bez problémů.
A co náročnější změny? Jako příklad uvedl Luis obsluhu podprocesů přerušení; jak se dá backportovat kód využívající tento druh obsluhy do jader, která takovou funkcionalitu neobsahují? Řešením v tomto případě bylo backportovat podprocesy obsluhy v samostatném modulu a přidat funkci compat_request_threaded_irq() pro backportované ovladače. Nejtěžší na tom ale bylo zjistit, kam umístit ukazatel na potřebná soukromá data. Vznikla složitá sémantická oprava nástroje Coccinelle, která zjišťuje, jakou datovou strukturu každý řadič používá k reprezentaci svého zařízení, potom na ni přidá nový ukazatel. Takovým způsobem je možné provést backport v automatizovaném režimu pro všechny ovladače.
Louis vysvětlil, že díky použití Coccinelle k backportování je celá práce jednodušší a konzistentnější; s tímto nástrojem je tým schopen backportovat mnohem více ovladačů. Díky vytvoření jednoho pravidla Coccinelle pro každou relevantní verzi jádra může tým držet krok se změnami jádra a získat pro všechny praktické účely automatické backporty pro širokou škálu ovladačů. Podle Luise je opodstatněné, aby byly sémantické opravy pro backportování součástí hlavní verze jádra – nikdo však takovou opravu ovšem ještě nenavrhl.
Vývojáři jádra se snaží minimalizovat využití konstrukcí #ifdef, ale ve zdrojovém stromu jádra jich je stále obrovské množství. Zajímavé podle Valentina Rotberga je, že mnoho z těchto bloků nedává ve skutečnosti smysl. V mnoha případech nelze možnosti konfigurace jádra zkombinovat tak, aby šlo jádro úspěšně sestavit; daný blok je tedy mrtvý kód. V jiných případech půjde kód zkompilovat ve všech případech; Valentin proto takový nazývá kód „nemrtvý“.
Mrtvý a nemrtvý kód může vzniknout z různých důvodů. Jednou z příčin mohou být překlepy v názvech symbolů CONFIG_; neznámý identifikátor je jednoduše vyhodnocen jako NEPRAVDA, místo aby byla vyvolána chyba. Někdy nejsou symboly konfigurace skutečně nezávislé; představte si CONFIG_BAR, který lze nastavit teprve po nastavení CONFIG_FOO. Pokud vidíte kód jako:
#ifdef CONFIG_BAR
/* ... */
#ifndef CONFIG_FOO
/* tento kód je mrtvý */
#endif
#endif
víte, že blok kódu uprostřed nebude nikdy přeložen. Tímto druhem logické chyby je způsobeno asi 25 % všech mrtvých/nemrtvých bloků kódu v jádru. Valentin nalezl celkem více než 1 000 mrtvých nebo nemrtvý bloků ve verzi jádra 2.6.29; tento počet se snížil na zhruba 600 ve verzi 3.17 – což je zlepšení, ale stále příliš mnoho. Tyto bloky #ifdef jsou záměrně podmíněné; mrtvé nebo nemrtvé bloky jdou proti tomuto záměru. Někdy také skrývají chyby; Valentin našel chybu nevracení paměti způsobenou chybou v CONFIG_HOTPLUG_CPU.
Řešením tohoto problému je použít Valetinův nástroj undertaker-checkpatch. Tento nástroj vyhodnotí opravu, poznamená změny do bloku #ifdef a označí veškerý mrtvý nebo nemrtvý kód, který nalezne. Opravy kontrolované tímto způsobem by neměly do jádra přidávat další problémy související s #ifdef. Undertaker je k dispozici na této webové stránce.
Editor LWN se zeptal, proč nebyla tato práce, která vypadá užitečně, jednoduše integrovaná do checkpatch.pl a začleněna do hlavního stromu. Zdá se, že existuje několik problémů spojených s touto myšlenkou, počínaje tím, undertaker-checkpatch je napsaný v C++. Navíc pracuje několik minut, což nemusí vývojářům v rámci běžného procesu vyhovovat. Valentin upozornil, že přece jen jde o výzkumný projekt; vývojáři nemají dost času a motivace změnit ho na produkční kód.
Tudíž se zdá, že undertaker-checkpatch by mohl potkat osud mnoha jiných akademických projektů. Ale existuje ještě jeden způsob, jak tento nástroj nadále používat v komunitě vývojářů jádra: integrovat ho do reaktivních testování systému Feng-kuang Wua. Pak vývojáři dostanou zdvořilý e-mail, když do jádra přidají problémy spojené s #ifdef. To je Valentinem doporučený způsob, jak by mohl být tento nástroj užitečný komunitě vývojářů jádra.
Projekt, který úzce souvisí s nástrojem Undertaker, je Vampyr, na němž pracuje na stejná skupina vývojářů. Stefan Hengelein popsal základní problém, který se snaží Vampyr řešit: skutečnost, že většina oprav jádra se testuje pouze na jedné nebo dvou konfiguracích jádra. Ale skutečný konfigurační prostor pro jádro je obrovský, a často není těžké najít kombinace konfiguračních parametrů, které nefungují tak, jak bylo zamýšleno.
Stefan řekl, že proto je opravy nutné kontrolovat se všemi příslušnými možnostmi konfigurace. To je těžko proveditelné a vyžaduje spoustu času na přemýšlení. Aktuální jádra mají téměř 14 000 možností konfigurace; je otázkou, zda je k dispozici dostatek lidí na kontrolu kódu se všemi možnými kombinacemi konfigurace.
Alternativou je nástroj Vampyr, jehož cílem je vytvořit „maximalizovanou sadu“ konfigurací jádra pro danou opravu. Prohledává konfigurační prostor a nachází kombinace, které muhou způsobit sestavení odlišného kódu. Výsledkem je obvykle několik konfigurací, z nichž každá slouží k testování sestavení.
Pomocí nástroje Vampyr se vývojářům podařilo objevit mnoho varování a jasných chyb. Kód x86 generuje o 15 % více varování při použití nástroje Vampyr, zatímco MIPS se zvyšuje o 58 %. S architekturou ARM využití nástroje Vampyr téměř zdvojnásobilo počet varování a vyústilo v identifikaci 91 potvrzených chyb. Stefan řekl, že se situace zlepšila v novějších jádrech, zejména v kódu x86; ostatní architektury se tolik nezlepšila.
Kód je k dispozici v rámci licence GPL v3; je k dispozici na webu nástroje Undertaker.
[Editor LWN by chtěl poděkovat nadaci Linux Foundation za podporu jeho cesty na konferenci linuxových instalatérů.]
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.