Jaderné noviny - 17. 8. 2017: Škálovaní souboru MAINTAINERS v jádře

26. 9. 2017 | Redakce

Články - Jaderné noviny - 17. 8. 2017: Škálovaní souboru MAINTAINERS v jádře  

Stav vydání jádra. Seznam regresí ze 12. srpna. Citát týdne: Rusty Russel. Škálování souboru MAINTAINERS v jádře.

Stav vydání jádra

Současné vývojové jádro bylo 4.13-rc5 vydané 13. srpna.

Seznam regresí ze 12. srpna čítá 11 známých problémů v jádře 4.13-rc5.

Stabilní aktualizace: Tohle byl pro stabilní vydání rušný týden. Verze 4.12.6, 4.9.42, 4.4.81 a 3.18.64 byly vydány 11. srpna, rychle je následovaly verze 4.12.7, 4.9.43, 4.4.82 a 3.18.65 13. srpna. Dne 16. srpna byly vydány stabilní verze 4.12.8, 4.9.44, 4.4.83 a 3.18.66.

Citát týdne

Mým kolegům správcům: Zůstaňte ostražití a nebojte se říkat „NE“ a „Proč?“ Špatných nápadů je víc než těch dobrých a složitost je pro nás hackery-můry jako svíčka. Ale buďte mírní, milí a odpouštějte svým kolegům: respekt od lidí, které respektujete je obvykle jediná odměna, která má hodnotu.

Sbohem všichni, těším se, až se zase potkáme!"

—Rusty Russel

Škálování souboru MAINTAINERS v jádře

Scaling the kernel's MAINTAINERS file. Jonathan Corbet. 10. srpna 2017

Komunita vývojářů jádra je tak velká, že někdy není jasné, komu by se měl daný patch poslat. Jak komunita rostla, vyvinuly se v ní mechanismy pro sledování těchto informací zvláště v textovém souboru pojmenovaném MAINTAINERS. Nyní se však zdá, že má tento škálovací mechanismus vlastní problém se škálovatelností.

Soubor MAINTAINERS se nachází na vrcholku stromu se zdrojovými kódy jádra. Jedná se o prostý textový soubor s řadou polí, která popisují, jak jsou řízeny různé podsystémy jádra. Například následující záznam byl konzultován pro účely nedávného článku o problémech stromů zařízení:

OPEN FIRMWARE AND FLATTENED DEVICE TREE
M:	Rob Herring <robh+dt@———>
M:	Frank Rowand <frowand.list@———>
L:	devicetree@vger.kernel.org
W:	http://www.devicetree.org/
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
S:	Maintained
F:	drivers/of/
F:	include/linux/of*.h
F:	scripts/dtc/
F:	Documentation/ABI/testing/sysfs-firmware-ofw

Tento záznam říká, že subsystém zploštěných (flattened) stromů zařízení má dva správce (pole „M:“), Roba Herringa a Franka Rowanda. Dále má zadanou poštovní konferenci (L:) a webovou stránku (W:), jakožto i strom subsystému v Gitu (T:). Řádky začínající F: popisují soubory a adresáře, které jsou považovány za součást subsystému. Soubor se dá číst v textovém editoru, ale často se s ním pracuje skrze skript get_maintainer.pl, který přečte patch a vygeneruje seznam adres, na které by daný patch měl být poslán.

Soubor je v současných jádrech delší než 14 tisíc řádků a obsahuje záznamy o více než 1700 jaderných subsystémech. Zdálo by se, že subsystémy jsou seřazeny podle abecedy, ale jak poznamenal Randy Dunlap v patchi z července, mnoho záznamů není na svém správném místě. Jeho patch se snažil tohle vyřešit, ale právě tady začaly skutečné problémy.

V tak velké komunitě, jako je ta jaderná, se změny subsystémů dějí často. Pokud dávají správní správci pozor, tyto změny vedou k patchům souboru MAINTAINERS – řádově stovkám patchů v každém vývojovém cyklu. Netřeba dodávat, že některé patche budou kolidovat s jinými, načež tenhle nepořádek musí odstranit Linus Torvalds. Když Dunlapův patch nevyhnutelně vyústil v konflikt při slučování, dal Torvalds najevo svou nespokojenost se souborem MAINTAINERS. Zeptal se, zda by soubor nešlo rozdělit.

Jeho původním návrhem bylo šířit informace o správcích stromem zdrojových kódů jádra, stejně jako byl rozdělen konfigurační soubor jádra počínaje vydáním 1.3.36. Později navrhl, že by informace o správcích mohla sídlit v souborech Kconfig vedle konfiguračních voleb, i když tenhle nápad se daleko nedostal. Bez ohledu na konkrétní schéma, vysvětlil, by rozdělení informací o správcích ulehčilo řešení konfliktů.

Výhody méně frustrovaného Linus Torvaldse jsou zřejmé většině vývojářů jádra, takže zájem o vylepšení souboru MAINTAINERS je poměrně velký. Joe Perches navrhl rozdělit soubor MAINTAINERS do adresáře na nejvyšší úrovni stromu, což by umožnilo snadný přístup k informacím a skriptům by se s nimi také lépe pracovalo. A to by zřejmě opravdu mohla být cesta, kterou se věci budou ubírat.

Zůstává tedy otázka, jak soubor rozdělit. Další Torvaldsův návrh byl rozdělit soubor podle poštovních konferencí, aby všechny záznamy mířící do stejné konference skončily ve stejném souboru. Perches se ale vrátil se skriptem, který místo toho rozděluje soubor podle hierarchie adresářů. Výsledkem je 54 souborů, pojmenovaných namátkou arch_arm64, drivers_gpu_drm nebo filesystems, v adresáři MAINTAINERS. Subsystémy, které neobsahují dostatečné množství záznamů, aby si zasloužily vlastní soubor, skončí v MAINTAINERS/MAINTAINERS.

Torvalds to vyzkoušel, ale rozhodl se, že tudy ne. Měl k rozdělení nějaké poznámky, ale dospěl k závěru, že „*něco* z toho vypadá velmi dobře.“ Ovšem obava, která věci zastavila, byla všem známá. Provedení této změny povede ke konfliktům při začleňováním dotýkajícím se libovolného stromu subsystému, který bude obsahovat změny souboru MAINTAINERS. Nejpravděpodobnějším řešením tohoto problému je provést změnu bezprostředně po vydání verze 4.14-rc1. Torvalds sice neslíbil, že se tomu tak stane, ale vypadá to, že k rozdělení MAINTAINERS v dohledné době opravdu dojde.

Diskuse k tomuto článku

[kralyk z abclinuxu]

Při pohledu do stromu aktuálního 4.14-rc2 tam vidim stále ten stejný MAINTAINERS file. Takže se asi nic nestalo. Ví někdo proč?

[pc2005]

Pravděpodobně se to klasicky protáhlo. Pokud na tom dělá jeden člověk a MAINTAINERS je klasický soubor, který souvisí se všema branchema, tak stačí nějaká drobná chybka a celý se to zpozdí.

BTW Se divím že ty informace nenacpou přímo do gitu, ten už jaksi z principu trackuje všechny soubory v repozitáři. Akorát teda ne všechny mirrory kernelu obsahují i git databázi.

[Sten]

Kam by se to dalo do gitu? Poznámky ke commitům (či objektům, pokud by se git rozšířil) se nepřenesou na novější verze a xattr nepodporuje.

[pc2005]

git blame ti napíše jméno autora každého řádku v libovolném trackovaném souboru. Takže by stačila nějaká úprava, kde by se zaznamenával navíc záznam o maintainerovi a mailing listu daného souboru. Určitě by bylo potřeba upravit kód gitu (aby se proskenovaly všechny objekty), ale neviděl bych to jako problém na pár měsíců.

Když nad tím tak uvažuju, tak se vlastně divím, proč na začátku každýho céčkovýho zdrojáku nemaj vedle klasického GNU copyrightu v tom komentáři i odkaz na maintainery, mailing list apod. Dokumentace a skripty asi jsou mimo C šablonu, ale všude je možnost mít komentář.

[pavlix]

Copyrighty na začátku souborů obecně fungují velmi špatně. Nechávají se tam, protože je v zásadě nelze odstranit. Ale že by se tam reálně udržovaly platné informace, to jedině snad v projektech, kde je to nějak zautomatizované, ale neviděl jsem to.

[sachy]

V projektu na kterem delam, je na zacatku kazdeho zdrojaku nekolik desitek/stovek jednoradkovych "logu zmen" - datum, autor, ticket (cislo ticketu se opakuje v komentari u kazdeho radku, ktery se menil) a popis. A ne, zadna automatika na to (po desitkach let vyvoje) neexistuje.

[Josef Kufner]

To jako že se duplikuje git blame? Není to poněkud zvrhlé?

[Kate]

Proč duplikuje? Až příliš předpokládáš že měli i jinou formu označení změn a jejich autorů :) V jedné firmě kde jsem chvilku pracovala jakoukoliv formu VCS prostě odmítali znát a verzovalo se komentářema, včetně vkládání dvou komentářů uvozující přidané řádky a „mazání“ kódu taktéž tagovaným zakomentováním. Peklo…