Portál AbcLinuxu, 24. dubna 2024 13:15
Stav vydání jádra. Konec jprobes. Výzva k nominaci volených členů Linux Foundation Technical Advisory Board. Citát týdne: Bruce Fields. Tlačení funkcí do vydání jádra s dlouhou podporou.
Současné vývojové jádro je 4.14-rc4, vydané 8. října.
Seznam regresí z 8. října ukazuje osm známých problémů v jádře 4.14-rc.
Stabilní aktualizace: 4.13.5, 4.9.53, 4.4.90 a 3.18.73 byly vydány 5. října. Následovaly je 4.9.54, 4.4.91 a 3.18.74 8. října. Dále 4.13.6, 4.9.55, 4.4.92 a 3.18.75 byly v době psaní tohoto článku v procesu revidování, vyšly 12. října.
„Jprobes“ je starý jaderný mechanismus, který se používal ke sledování vstupu do jaderných funkcí. Píše se o něm v tomto článku na LWN z roku 2005. Nedávno dospěla jaderná komunita k záběru, že jprobes už mají jen málo uživatelů (jestli vůbec nějaké), dávno je nahradil mechanismus sledování funkcí (ftrace) a jsou náročné na údržbu. Výsledkem je, že API jprobe nejspíš bude v některém z budoucích jader zakázáno. Pokud tedy někdo jprobes stále používá, nyní je vhodné, aby buď přešel na něco jiného, nebo dal vědět, že stojí o jejich zachování v jádře.
Další volba členů Linux Foundation Technical Advisory Board se bude konat 25. října na Kernel Summitu v Praze. Výzva je určena kandidátům, kteří by obsadili celkem pět volných pozic. „Linux Foundation Technical Advisory Board (TAB) slouží jako rozhraní mezi komunitou jaderných vývojářů a nadací. TAB radí nadaci v záležitostech spojených s jádrem, pomáhá členským společnostem pracovat s komunitou a pracuje na řešení problémů spojených s komunitou, než se vymknou kontrole. Rada má deset členů, jeden z nich je členem představenstva LF.“
Zvláštně mi zalichotila myšlenka, že si spousta náhodných lidi najednou začala myslet, že já a Jeff jsme experti na VFS. Ukázalo se, že šlo pouze o překlep.
Cramming features into LTS kernel releases. Jonathan Corbet. 10. říjen 2017
Přestože se vývojový cyklus 4.14 zatím nestal nejrušnějším cyklem vůbec (v době psaní toho článku bylo začleněno 12 500 změn, o něco víc než ve stejné fázi cyklu 4.13), dosud se jevil nepříjemnější než jeho předchůdci. Jsou různé důvody, proč jdou některé cykly snáze než jiné, ale není nerozumné se zajímat, zda skutečnost, že 4.14 je vydání s dlouhodobou podporou (LTS), ovlivnila průběh tohoto cyklu. Vskutku, Linus Torvalds si při vydání 4.14-rc3 postěžoval, že tento cyklus byl mnohem bolestivější než obvykle, a nadhodil, že očekávaná dlouhodobá podpora vydání by mohla být součástí problému. Několik nedávných začlenění do hlavního repozitáře poukazuje na tlak, který se týká LTS vydání.
Jak bylo popsáno v tomto článku, bude jádro 4.14 obsahovat některé změny API jaderných časovačů, směřující k jejich zefektivnění, přiblížení současným API v jádře a usnadnění tvrzení. Ačkoliv jsou změny API běžně vyhrazeny pro začleňovací okno, tato změna byla do hlavního repozitáře zařazena ve vydání 4.13-rc3. Pozdní začlenění vedlo v komunitě k troše reptání.
Problémem není nutně přidání funkce timer_setup(), která sama o sobě nemůže nic rozbít. Ale její přidání následovala řada přechodů na nová rozhraní, které jsou zasílány příslušným správcům. Přijetí přechodu na timer_setup() do stromu správce bude fungovat pouze v případě, že tento strom obsahuje timer_setup() samotný, což znamená, že strom správce musí být stejně aktuální jako hlavní strom, tedy aspoň verze 4.14-rc3. Mnoho správců subsystémů používá vlastní větve založené na hlavním stromu rc-1 nebo rc-2, takže pak nemohou aplikovat konverzní patche, pokud sami nejdříve zvlášť neprovedou příslušné začlenění. Toto začlenění obvykle nebývá složité, ale stromy subsystémů, které obsahují „zpětná začlenění“ z hlavního repozitáře, mohou během začleňovacího okna narazit na komplikace, takže si na ně správci pochopitelně dávají pozor.
V tomto případě se reptání již odbylo a lze očekávat, že přechod na nové API časovačů bude podle plánu dokončen v cyklu 4.15. A konkrétněji, kdo bude chtít přenést více konverzí zpětně do vydání 4.14 (aby je měl v jádře s dlouhodobou podporou, které bude v mnoha mobilních zařízeních), s tím bude mít mnohem jednodušší práci. Nikdy nebylo výslovně řečeno, že pro tuto práci je důležitým cílem zrovna vydání 4.14, ale zdá se nepravděpodobné, že by na to vývojáři nemysleli.
V jiném případě byly věci jasnější. Thomas Gleixner nedávno poslal žádost o začlenění významně refaktorovaného subsystému watchdog časovačů. Šlo o přepracovanou verzi sady patchů, kterou Torvalds odmítl během začleňovacího okna. Součástí odůvodnění žádosti o začlenění tak pozdě ve vývojovém cyklu byla snaha dostat tuto práci do právě tohoto vydání:
Jelikož je 4.14 dlouhodobě stabilní jádro, dal bych přednost tomu mít v něm funkční kód watchdogu a vyřešené problémy s lockdep. Nežádal bych tě o začlenění, kdyby 4.14 nebylo LTS vydání jádra nebo bylo snadné řešení backportovat.
Správce stabilního jádra, Greg Kroah-Hartman, si na tuto žádost postěžoval: „Přesně tohle jsem _NEchtěl_ vidět, když jsem oznámil vydání LTS jádra předem.“ Navrhl, že možná by se budoucí oznámení o dlouhodobé podpoře měla vrátit až do doby po vydání příslušného jádra. Každopádně Torvalds změny do jádra 4.14-rc4 začlenil bez komentáře.
Tato práce téměř jistě jádro 4.14 nerozbije, byla v podstatě hotová už během začleňovacího okna. Ale ukazuje, že LTS vydání motivují žádosti o začlenění, které by jinak mohly počkat na příští cyklus. Takhle by to fungovat nemělo. Část myšlenky za devítitýdenním cyklem vydání je – protože cena nestihnutí jednoho cyklu je minimální – že by neměl být žádný zásadní důvod uspěchat dodání kódu do konkrétního vydání. Je však zřejmé, že ten zcela nezmizel a naopak může dokonce sílit.
Pro ty, kdo se pohybují v jaderné komunitě, vypadá jeden cyklus jako druhý. Ale z pohledu uživatelů jádra rozhodně nejsou žádná dvě vydání stejná. Když někdo plánuje distribuovat některé vydání jádra, zajímá ho právě toto vydání. Bylo vynaloženo úsilí, aby dodavatelé distribuovali LTS jádra, s nadějí, že se obecně zlepší podpora příslušných jader nasazených v praxi. Tato snaha zaznamenala určitý úspěch, což je pozitivní změna, ale vede k tendenci soustřeďovat ještě větší úsilí na LTS vydání. To může vést jedině k většímu tlaku dostat do těchto vydání více funkcí.
V jistém smyslu se situace trochu podobá tomu, jak to fungovalo před vydáním 2.6. Stěžejní vydání jádra byla tehdy oddělena roky, takže existoval obrovský tlak dostat dovnitř funkce ještě před uzávěrkou. Jak se rozšiřuje používání LTS jáder, začíná to vypadat jako hlavní vydání starých jader. Všichni chtějí dostat své funkce do LTS vydání – a ta vycházejí jen jednou ročně. Promeškat LTS vydání znamená čekat rok, než se funkce dostane do dalšího LTS vydání, a pravděpodobně příslušné změny také udržovat mimo strom kvůli produktům, které budou dodány v mezičase. Není tedy divu, že nápad dostat svůj kód do hlavního repozitáře dříve, i když bude vyžadovat pozdější opravy, má něco do sebe, ale každá legrace něco stojí. Jak řekl Kroah-Hartman: „Tohle už jsme zkusili a nebylo to dobré.“
Je třeba říct, že jaderná komunita se od zavedení krátkých cyklů vydávání jádra podstatně proměnila. Obecně je kód při začlenění do hlavní větve na mnohem vyšší úrovni. Takže pokud se ho do vydání 4.14 tlačí trochu víc, může to mít za následek poněkud turbulentnější vývojový cyklus. Neměla by se ovšem opakovat situace jako před 15 či 20 lety, kdy si „stabilní“ jádro k úplné stabilizaci vyžádalo další rok. Pravděpodobně nám nehrozí riziko, že se bude opakovat utrpení z let raných vydání 2.x.
V tomto konkrétním případě není kvalita začleňovaného kódu předmětem sporu. Jde vlastně jen o otázku načasování a diskuze se poměrně rychle uklidnila. Dá se ale očekávat, že téma se vrátí. Nezmizí ani tlak dostat změny do LTS vydání, ani lidská touha pokoušet pravidla systému, i když odzvoní předběžnému ohlašování dlouhodobé podpory vydání.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.