Portál AbcLinuxu, 5. května 2025 19:08
Aktuální verze jádra: 2.6.19-rc4. Citát týdne: Harald Welte. Záplava varování. Nadcházející změna API: struct path.
Aktuální předverze je 2.6.19-rc4, vydaná 30. října. Obsahuje docela dost oprav, včetně té, která napravuje změnu, kvůli které nefungoval ndiswrapper. Podrobnosti v dlouhém changelogu.
V hlavním git repozitáři se stále hromadí patche; po vydání -rc4 byly zařazeny opravy síťového subsystému, změny eCryptfs a několik velkých aktualizací architektur.
Adrian Bunk i nadále spravuje seznam známých regresí v aktuálních předverzích řady 2.6.
Aktuální verze -mm stromu je 2.6.19-rc4-mm1. Mezi nedávné změny patří odstranění stromů ACPI a ovladačového jádra kvůli různým problémům a patche pro podporu paravirtualizace na i386.
Kolikrát už jsi viděl, že by kód, který vydávají (většinou embedded) výrobci pod GPL, byl doopravdy něčím užitečný, aby stálo za to jej začlenit do existujícího Free Software projektu, nebo ze kterého by dokonce vznikl nový Free Software projekt. Za sebe mohu říct: nikdy. Opravdové číslo možná není nula, ale bude to blízko.
-- Harald Welte
Předverze 2.6.19-rc4 nadělala více starostí, než by vývojářům bylo milé; zmatky kolem návratového typu interní funkce vedly k nežádoucímu pomíchání ukazatelových a celočíselných typů v hlubinách blokové vrstvy. Ukázalo se, že gcc o problému věděl a řádně na něj upozornil. Nikdo si však varování před začleněním patche nevšiml a výsledné jádro bylo vydáno. Jinými slovy: problém, kterému by mělo být snadné se vyhnout.
Linus reagoval takto:
A to mám zapnutý SYSFS, takže jsem to varování měl vidět.
Ale já už jsem k těm varováním slepý. Prostě proto, že máme tolik zbytečného balastu o zastaralosti a dalších pitomostech, a PPC má ještě navíc vlastní hromadu nesmyslných varování generovaných kompilátorem a linkerem.
Už bychom se měli zbavit všech těch varování "ze slušnosti", protože se mezi nimi ztrácejí ta _skutečná_.
Nejeden vývojář jádra si určitě pomyslel, proč to trvalo tak dlouho, než k tomu došlo - stížnosti na přehnané množství varování nejsou nic nového. Je velký zájem na tom, aby počítač sám nacházel problémy, kdykoliv je to možné. To vede ke stoupajícímu počtu značení "must check" [povinná kontrola] a dalším změnám, jež mají za následek vypsání varování, kdykoliv něco vypadá podezřele. Navíc gcc generuje slušné množství varování v situacích, kde žádné skutečné problémy nejsou. Výsledkem je, že varování týkající se opravdových problémů se v té záplavě ztratí.
Už nějakou dobu existují patche, které řeší mnohá varování typu "this variable might not be initialized before being used" [tato proměnná možná nebyla před použitím inicializována]. Ne všichni však souhlasí se začleněním; některým vývojářům se nelíbí představa zaneřádění (a zvětšení) jádra nepotřebnými inicializacemi kvůli něčemu, co považují za chybu gcc. Nic nenasvědčuje tomu, že by poslední epizodka nějak změnila pohled na věc; inicializační patche možná budou i nadále vyčkávat.
Al Viro na to šel jinak. Vyvinul malý nástroj nazývaný "remapper", který sleduje pohyb bloků kódu v jádře mezi jednotlivými verzemi. S pomocí generovaných informací může být sada varování kompilátoru přemapována ze starého jádra na odpovídající čísla řádků v novějším jádře. Pak je možné použít nástroj jako diff pro porovnání výstupu ze staré a nové kompilace; výsledkem je výpis pouze těch varování, která se objevila až u nového jádra. S takto filtrovaným výstupem mohou vývojáři snadno nalézt místa, kde kompilátor upozornil na skutečné problémy.
Remapper je možné stáhnout pomocí git:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/remapper.git
Dave Jones také připravuje každodenní verze.
Používání remapperu je poměrně jednoduché. Po kompilaci nástroje remap-log začnete příkazem:
diff-remap-data 2.6.19-rc2 2.6.19-rc3 > 2-to-3.map
Výsledný "map" soubor je plný názvů souborů a čísel; mapují čísla řádků za starého adresářového stromu do nového - a označují bloky kódu, které byly úplně odstraněny. Další nástroj (git-remap-data) provádí stejnou věc u dvou commitů v git repozitáři; v takovém případě je možné také správně zpracovat přejmenované soubory.
Nástroj remap-log může být využit k přesunutí starých logů kompilace do současných:
remap-log 2-to-3.map < 2.6.19-rc2.log > 2.6.19-rc2-remapped.log
Pokud je pak nový log pomocí diff porovnán s výstupem z kompilace verze 2.6.19-rc3, budou jediným výstupem varování (nebo chyby), které se objevily či zmizely oproti předchozí verzi. Takové, které se pouze posunuly kvůli změnám v souboru, budou odfiltrovány. Krátký dokumentační soubor přibalený ke kódu nabízí další možnosti použití.
Někteří vývojáři na tento nástroj nedají dopustit. Jeff Garzik však nebyl zrovna nadšen; v dřívější diskuzi řekl:
Myslím, že je zároveň smutné a výmluvné, když velké množství kompilačního šumu vytrénovalo vývojáře k imunitě před varováními a/nebo k přípravě čím dál důmyslnějších nástrojů pro vylovení užitečných zpráv ze všeho toho nepořádku.
Jeff místo toho sestavil samostatný strom jádra, kde je většina zbytečných varování odstraněna. Je to náročná práce - každé varování je nutno prověřit a prokázat, že je nesmyslné, než bude odstraněno. Není cílem tento kód začlenit; jde o vytvoření vývojové platformy, na které jsou vidět důležitá varování. Tato sada změn je součástí -mm od 2.6.18-mm3.
A ještě další způsob řešení varování typu "možná není inicializována" se objevil v květnu; zavádí speciální makro, které proměnnou "inicializuje", aniž by se ve skutečnosti něco stalo. To umlčí varování bez toho, aby se zvětšila velikost jádra. Makro je určeno k použití pouze v případech, kdy byly cesty kódu zkontrolovány. Tenkrát zazněla námitka, že ačkoliv je současné použití proměnné možná správné, budoucí změny by mohly vytvořit cestu, kde by proměnná byla skutečně použita bez inicializace. Varování by však bylo potlačeno a na chybu by se přišlo až mnohem později. Patch tedy nebyl začleněn.
Chyby v kompilátoru snad mohou být časem opraveny. Ale vzrůstající zájem o používání automatizovaných nástrojů pro hledání potenciálních chyb zaručuje, že se budou vývojáři muset i nadále potýkat s množstvím planých varování. Pokud by ta automatizovaná varování měla doopravdy vést k opravě chyb - než se někdo spálí - bude nutné najít způsob, jak udržet nízkou úroveň šumu.
Struktura file, která reprezentuje otevřený soubor, je předávána do většiny operací týkajících se souborových systémů a ovladačů. Obsahuje dvě užitečná pole:
struct dentry *f_dentry; struct vfsmount *f_vfsmnt;
Josef Šípek si nedávno všiml, že v fs/namei.c je podobně vypadající struktura, která je definována takto:
struct path {
struct vfsmount *mnt;
struct dentry *dentry;
};
Rozhodl se, že struct path si zaslouží větší rozšíření; výsledkem je série patchů přesouvající struct path do <linux/namei.h> a pozměňující struct file, aby používalo struct path místo těch dvou výše uvedených samostatných polí.
V jádře je samozřejmě nějaký kód, který struct file očekává na původním místě; konkrétně pole f_dentry je často používané. Takže tento přesun představuje změnu interního API, kterou dá práci napravit. Když byla celá sada patchů přidána do 2.6.19-rc3-mm1, Andrew Morton ji proto označil jako 102 patchů, které dělají cosi poněkud zbytečného.
Tak co za tím vězí? Josef to vysvětlil takto:
Je to o trochu čistší než mít dva ukazatele. Obecně lze říci, že v jádře je dost uživatelů dvojic dentry-vfsmount, a struct path to pěkně zaobaluje.
"O trochu čistší" se zdá jako dost slabý důvod pro patch, který manipuluje s tolika soubory a ovlivní i hodně kódu spravovaného mimo jádro. Dostalo se to však až do -mm, což napovídá, že je velká šance na začlenění do 2.6.20. Ať už zbytečné nebo ne, struct path má asi namířeno do jádra.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.