Jaderné noviny - 2. 2. 2017: Vendoring v jádře

22. 2. 2017 | Redakce

Články - Jaderné noviny - 2. 2. 2017: Vendoring v jádře  

Stav vydání jádra. Citáty týdne: Konstantin Ryabitsev a Ingo Molnár. Vendoring v jádře.

Stav vydání jádra

Současný vývojový kernel je 4.10-rc6, vydaný 29. ledna. Linus se obával, že aktivita tentokrát narostla. „Při pohledu do historie se nejedná o velké vydání, protože 4.10 byla celkem klidná, ale je to trochu nepříjemné. Doufal jsem, že konečně uděláme vydání rc7 jako poslední (jak 4.8, tak 4.9 měly rc8), a moc si přeju, aby se vše uklidnilo a aby tak mohlo k vydání dojít podle obvyklého plánu.“ Označení se znovu změnilo, tentokrát na „Fearless Coyote“.

Stabilní aktualizace: 4.9.6 a 4.4.45 byly vydány 26. ledna. Verze 4.9.7 a 4.4.46 byly v době psaní tohoto článku revidovány, k jejich vydání došlo 2. února.

Citáty týdne

Vzhledem k tomu, že se mě pořád někdo ptá: „hele, proč už nefunguje finger kernel.org?“, jsem si jistý, že mě otázka: „hele, co se stalo s ftp.kernel.org?“ bude pronásledovat až do důchodu.

—Konstantin Ryabitsev

Distribuční hlavičky UAPI (UAPI headers) fungují slušně ve světě, kde je jádro statickou entitou a neaktualizuje svoje ABI. Tzn. funguje pouze tehdy, když nejsou přítomna žádná rozšíření ABI ze strany jádra. Celý ten přístup kolem distribučních hlaviček UAPI je navržen pro případ, kdy na způsobu sdílení hlaviček záleží nejméně, tedy pro případ stagnace jádra a souvisejících nástrojů…

Mimochodem, tenhle rigidní, suboptimální, zpožděními zatížený způsob sdílení informací mezi jádrem a nástroji může být jedním z důvodů, proč je obecně nabídka linuxových nástrojů tak mizerná ve srovnání s jinými operačními systémy.

—Ingo Molnár

Ukončení služby FTP (kernel.org)

Kernel.org oznámil, že vypne přístup k archivům přes FTP ve dvou fázích: 1. března skončí ftp.kernel.org a 1. prosince bude ukončena činnost mirrors.kernel.org.

Přiznejme si to, i když je to tak trochu elegantní a pohodlné, nabízet veřejný NFS/CIFS server je Dost Špatný Nápad. Nejen proto, že oba tyto protokoly jsou při vysoké latenci dost hrozné, ale také z významných bezpečnostních důvodů.

Nuže, po 19 letech si myslíme, že je načase ukončit další službu, která má potenciální problémy spojené s protokolem a bezpečností – naše FTP servery. Naše rozhodnutí je vedeno následujícími úvahami:

• Protokol je neefektivní a vyžaduje lepení obezliček k firewallům a démonům vyrovnávajícím zátěž.
• FTP servery nepodporují kešování ani akcelerátory, což má výrazný dopad na výkon.
• Většina softwarových implementací stagnuje a aktualizace dostává nepravidelně.

Všechny FTP služby kernel.org budou ukončeny do konce tohoto roku.

LZ4: Vendoring v jádře

Robert Lefkowitz ve svém příspěvku na linux.conf.au 2017 hovořil o procesu „vendorizace“ – kopírování kódu z jiných projektů do vlastního repozitáře, namísto přijímání závislostí na těchto projektech. Vendoring je u komerčních projektů běžný, Android tak často činí a Lefkowitz navrhl, že by tato praxe měla být obvyklá i jinde. Vendoring přitom obecně není neznámý a probíhá také v jádře, jak naznačuje současná sada patchů.

Kompresní algoritmus ZL4 je údajně „velmi rychlý“, zvláště při dekompresi. V rámci testovacích výsledků se ukazuje, že LZ4 poráží dekompresi LZO o faktor čtyř a zlib dokonce řádově. Jedná se o bezztrátový algoritmus, takže se hodí ke kompresi dat, která je nutné obnovit v jejich původní podobě. Nedávné aktualizace přidaly „rychlý“ režim, který umožňuje volajícím ovládat kompromis mezi rychlostí a úrovní komprese.

Jde si představit, jak by takový druh rychlé komprese mohl být v jádro užitečný. A skutečně jádro funkcionalitu LZ4 od vydání 3.11 z roku 2013 má. Přidal ji Chanho Min, který přebral vydání r90 z repozitáře LZ4 a nacpal ho do jádra do lib/lz4. Rychlý grep ukazuje, že se rychlá komprese v současné době používá v šifrovací vrstvě, v subsystému pstore a v souborovém systému squashfs. V jádře jsou i další místa, která využívají kompresi, aktuálně to však není LZ4.

Jednou z výhod kopírování kódu do vlastního repozitáře je, že již nejste závislí na externí závislosti. Lefkowitz si myslel, že nezávislost byla tak cenná, že doporučoval kopírování pro jakoukoli závislost s nejvýše 35 miliony řádek. V případě jádra hovoří proti externím závislostem jeden velmi silný argument. Jádro musí být sestaveno jako samostatný program s využitím svých vlastních komplikovaných sad pravidel linkeru. Pravděpodobně je možné vyladit systém sestavení jádra tak, aby bylo možné se linkovat ke knihovnám zvenku, ale dá se předpokládat, že proti takovému kroku by se zvedla vlna odporu. Vývojáři jádra chtějí přesně vědět, co se do výsledného produktu dostane.

Nevýhodou vendoringu je samozřejmě to, přijdete o všechna vylepšení provedená v původním projektu. Vývojáři LZ4 vydali od roku 2013 řadu verzí, přidali díky nim mnoho funkcí, včetně „rychlého režimu LZ4“. Některé z těchto změn možná opravily chyby, které by v jádře byly bezpečnostního charakteru. Žádná z těchto změn se však v současných jádrech nenachází.

K začátku roku poslal Sven Schmidt sadu patchů, která aktualizovala LZ4 k vydání projektu ve verzi 1.7.2. Motivací byla touha použít rychlý režim LZ4 v souborovém systému Lustre, ale správně předpokládal, že by rychlého režimu mohly chtít využít také další části jádra. Tyto patche představují celkovou náhradu existujícího kódu LZ4; práce Mina, která měla za cíl přeměnit knihovnu LZ4 do modulu jádra, tím byla replikována.

Proti upgradu jaderné implementace LZ4 se zatím neobjevily žádné námitky, ale Greg Kroah-Hartman poznamenal, že jeden potenciální problém existuje, a zdůraznil další nebezpečí, spojené s vendoringem. Existující jaderná implementace z roku 2013 nebyla dlouho beze změny, dočkala se mnoha patchů. Některé z nich byly bezpečnostní opravy. Když Schmidt implementaci LZ4 nahradil, nahradil také tyto opravy, takže možná znovu zavedl problémy, které se již podařilo odstranit.

Jakmile se podařilo k této otázce přitáhnout jeho pozornost, Schmidt souhlasil s tím, že se na patche podívá a ujistí se, že jeho náhrady nevedou k návratu starých problémů. Se štěstím se mu snad podaří začlenit relevantní změny do upstreamu, i když Willy Tarreau namítl, že některé změny jsou přinejmenším specifické pro jádro. Pokud takové změny existují, do upstreamu se pravděpodobně nedostanou a jádro je bude muset udržovat napořád.

Ujistit se, že nový kód LZ4 obsahuje opravy aplikované na starý kód, není těžký úkol, počet patchů je malý. Naštěstí existují jako samostatné patche, místo aby byly v tichosti vloženy do zdrojového kódu v době, kdy byl kód LZ4 přidán do jádra. Ale jedná se o úkol, na který je třeba myslet pokaždé, když se někdo implementaci LZ4 pro jádro rozhodně aktualizovat. V tomto případě si Kroah-Hartman všiml problému, ale projekt nemůže vždy spoléhat na jeho pozornost, aby nedošlo k regresi u budoucích aktualizací.

K takovým aktualizacím jistě dříve nebo později dojde. Upstream projektu LZ4 byl v době psaní tohoto článku u verze 1.7.6, došlo k přidání režimu vysoké komprese a opravě chyb, které se objevily od vydání verze 1.7.2. Za nějaký čas bude někdo pracující na jádře chtít, aby se tato vylepšení do něj dostala.

Jádro obsahuje další zkopírované subsystémy jako LZ4, většinou se jedná o nízkoúrovňový kompresní a šifrovací kód. Každý takový kód představuje určitý typ odpojení od upstreamu projektu (v případech, kdy je původní upstream stále ještě aktivní). Dá se říct, že výrazně modifikovaná jádra pro mobilní a embedded systémy představují za další případ téhož. Místo toho, aby vlastní kód dostali do upstreamu, kopírují ho výrobci z jednoho jádra do druhého.

Pro vendoring existují pádné důvody, ale jsou s ním spojené skutečné náklady. Převaha vendoringu v celé komunitě naznačuje, že se stále snažíme najít nejlepší způsob, jak integrovat kód vytvořený nezávislými skupinami vývojářů, zvláště jak narůstá rozsah vlastních projektů. Pro tuto chvíli musíme doufat, že až se příště někdo rozhodne aktualizovat knihovnu LZ4 v jádře, nezapomene na staré opravy a ujistí se, že budou přeneseny do nové verze.

Diskuse k tomuto článku

[Josef Kufner]

Ad vendoring: Divím se, že nepoužijí submoduly a vlastní repozitáře (klony upstreamu). Aktualizace by to zjednodušilo a výhody zachovalo.

[pavlix]

To bylo taky první, co mě napadlo. Submoduly sice přinášejí drobné komplikace, ale tohle to docela dobře řeší a vypořádá se to elegantně právě i s tím patchováním oproti upstreamu. Ale asi je to samo o sobě velké rozhodnutí, tak bylo prostě pohodlnější to tam nacpat než to řešit nějak víc.

[andree]

Zrovna na ten lz4 by ani submodul nebolo treba - v zasade by asi mohlo stacit naimportovat to na zaciatku ako samostatny branch (aby sedeli commit hash-e), pak to zamergeovat do jadra a je to. Kazdy dalsi update len prida commity z upstreamu, ktore sa znovu zamergeuju. Ale nevidim dovod, aby to nemohlo ist dodatocne (akurat to vyzaduje opatrnejsi pristup)...

[Petr Tomášek]

Aha, takže tu prasárnu teď začínají nazývat "vendoring". Výsledek bude mnoho kopií zabugovaného kódu, který nikdo neudržuje.

Ať žijou komerční prasata!

[pavlix]

No jo, dřív se tomu říkalo bundling a bylo to špatné.

[Blaazen]

Origoš: Lefkowitz thought that independence was so valuable that he recommended copying for any dependency with less than about 35 million lines.

Překlad: Lefkowitz si myslel, že nezávislost byla tak cenná, že doporučoval kopírování pro jakoukoli závislost s nejméně 35 miliony řádek.

[Fluttershy, yay!]

Oops. Ani mně se to moc nezdálo, ale z nějakého záhadného důvodu jsem to tehdy neopravil. Tak díky za připomenutí.