Portál AbcLinuxu, 7. května 2025 05:50
Aktuální verze jádra: 3.11-rc1. Citáty týdne: Ingo Molnar, James Bottomley.Začleňovací okno 3.11 se uzavírá. Problémy se stabilním stromem.
Aktuální vývojová verze jádra je 3.11-rc1 vydaná 14. července. Kromě začleňování v lustre šlo o poněkud klidnější začleňovací okno. Měli jsme méně stromů s problémy a k tomu pokračující debatu o stabilních patchích, která se rozjela hlavně kvůli tomuto začleňovacímu oknu, takže teď aspoň bude na jaderném sumitu o čem diskutovat. Celkově vzato bych ale řekl, že se začíná projevovat tradiční letní propad (vyjma Austrálie). Toto vydání má bohužel i nové kódové označení: „Linux pro pracovní skupiny“.
Stabilní aktualizace: verze 3.10.1, 3.9.10, 3.4.53 a 3.0.86 všechny vyšly 13. července. Greg upozorňuje na to, že verze 3.9.10 může být poslední v řadě 3.9.x.
Hluboko v našich sklepích nás toho konec konců nemůže moc zranit, snad kromě zemětřesení, erupcí gama záření a mámy, co se snaží uklidit kolem počítačů.
-- Ingo Molnar
Vůbec mi nevadí provozovat linux-scsi na základě rozumných standardů zdvořilého chování a snahy udržovat diskuzi v technické rovině, ale to se mnohem snáze realizuje na mailing listu s nízkým provozem; je mi jasné, že tento způsob argumentace se nemusí všem líbit, proto nejde o standardní chování, které bych chtěl všude nutit. Pravdou je, že bych něchtěl, aby se kdekoliv nutilo *jakékoliv* chování... jde v podstatě jen o zástěrku bojů o moc (nebo to k tomu bude brzo zneužité); jediný skutečný způsob, jak dosáhnout nějakého standardu v chování je jít příkladem, nikoliv pomocí nařízení.
Linus oznámil vydání verze 3.11-rc1 – a uzavření začleňovacího okna – 14. července. Do té doby bylo začleněno 9494 neslučovacích sad změn. Poslední z těchto změn změnila kódové označení jádra na „Linux pro pracovní skuoiny“ a upravila logo při bootu. Vývoj Linuxu se jednoznačně přesunul do nové éry.
Z 9494 změn bylo 1219 přetaženo od souhrnu z minulého týdne. Mezi změny viditelné uživatelům patří:
Mezi změny viditelné vývojářům jádra patří:
Poslední vývojové cykly vždy trvaly přibližně 70 dnů (i když 3.10 se svými 63 dny bylo znatelně kratší). Vydání jádra 3.11 bychom proto mohli očekávat přibližně 9. září.
V dávné minulosti (březen 2005) vedli vývojáři jádra rozsáhlou debatu o různých problémech s vývojovým cyklem, jedním z nich byla nemožnost dostat opravy určené pro stabilní vydání jádra k uživatelům. Linus navrhl, že by se mohl udržovat oddělený strom pro opravy, pokud by se našel vhodný „ořežprut“, který by se o to staral, ale odhadoval, že by se za pár dnů zbláznil a vzdal by to. Ukázalo se, že Linus nepočítal s tvrdošijností Grega Kroah-Hartmana; Greg (tehdy s Chrisem Wrightem) se nabídl a dobrovolně začal tento strom udržovat, počínaje vydáním verze 2.6.11.1. Od té doby Greg udržuje stabilní stromy. Nedávno se ale podělil o svá trápení s procesy.
Zejména pak oznámení o revidování vydání 3.10.1 zahrnovalo hlasitou stížnost na to, jak správci subsystémů spravují patche pro stabilní strom. Konkrétně by rád viděl, kdyby se změnily dvě následující věci:
Odpověď na druhou stížnost je docela jasná: přesvědčit Grega, aby přijal změny do stabilního stromu, je snazší, než přesvědčit Linuse, aby je přijal mimo začleňovací okno. Teoreticky jsou pravidla pro začlenění v obou případech stejná: patche musí řešit nějaký „kritický“ problém. V praxi to vypadá, že Greg a Linus alespoň zdánlivě tato pravidla chápou odlišně. Proto vývojáři, než aby riskovali rozčilení Linuse, jednoduše počkají na následující začleňovací okno. Jak to ostatně vysvětlil James Bottomley:
Myslíš to, že zdržujeme opravy až do začleňovacího okna (ty označené pro stable), protože je nemůžeme dostat do -rc5 nebo pozdějších? Jsem vinen... to proto, že dostat něco do jádra je čím dál těžší. Dostat tam něco drobného po -rc5 je velký boj... je snazší to tiše označit pro stable.
Gregův plán na zlepšení spočívá ve sledování linux-next počínaje -rc4. Pokud se patche označené pro stable začnou objevovat ve stable, pak se bude ptát správců, proč se ještě nedostaly k Linusovi. Některé z těchto patchů nemusejí být přijaty do stabilního stromu, pokud se objeví v hlavní řadě během začleňovacího okna.
Téma nevhodných patchů, ačkoliv tvořilo menší část Gregových stížností, se stalo důležitější částí následující debaty. Vypadá to, že se najdou důvody, proč patche směřovat do stabilního stromu, i když pro něj nejsou úplně vhodné. Jedním extrémním případem, který strojí za přečtení, je ten od Bena Herrenschmidta – popisuje, jak potřeba dostat kód do enterprise jader pohání vývojový proces. V ostatních případech jsou ale důvody spíše přímočařejší.
Celé roky měli lidé obavy, že jsou důležité opravy přehlíženy a nedostávají se do stabilních aktualizací; to vedlo k tlaku na vývojáře, aby příslušné patche připravovali pro stabilní strom. Toto úsilí bylo docela úspěšné, a to dokonce tak, že vývojáři nyní často přidávají tag „stable“ k patchi opravujícímu chybu už jen ze zvyku. Správci subsystémů by měli tyto tagy revidovat při revizi patche, ale k tomu nemusí vždy dojít – nebo tito správci mohou souhlasit s tím, že patch má jít do stabilního stromu, i když nesplňuje pravidla. A občas správci subsystémů nemohou tag odstranit, i když chtějí. Toto všechno vedlo Jamese k návrhu tagu stable se zbavit:
Skutečným původcem problému je to, že tag cc: stable nelze odstranit, jakmile je ve stromu, takže správci mají možnost kontrolovat jen věci, co do stromu dávají. Věci, které přetahují od jiných, jsou už otagované a tento tag nelze změnit. To ve výsledku přenáší problém na nejnižší (a možná i nejméně zkušené) listy ve Stromu správců.
James (stejně jako jiní) navrhuje, aby zařazení patche do stabilního stromu vyžadovalo explicitní úkon ze strany správce subsystému. Ale Gregovi se tento nápad nelíbí, jelikož správci jsou už tak moc zaneprázdnění. Smyslem procesu pro stabilní stromy je věci pro všechny ostatní co nejvíce usnadnit; přidávání zátěže by mohlo úspěch ohrozit. To platí i kvůli tomu, že někteří vývojáři by mohli narazit u svých zaměstnavatelů:
A nejvíce mě rozčiluje to, že některé firmy mají pocit, že s nimi stabilní jádra soupeří. Proto se lidé pracující pro tyto firmy nemusejí setkat s pochopením, když by pro stabilní vydání jader měli dělat práci navíc (to nejsou jen babské povídačky, toto jsem slyšel přímo z úst manažerů).
Dalším zastáncem zapojení správců v procesu je Jiří Kosina, který během své práce na jádrech v SUSE narazil na několik problémů se stabilními jádry. Ačkoliv si stabilního stromu vysoce cení, některé patche v něm způsobují regrese, některé jsou zkrátka na nic a u některých není vůbec jasné, proč jsou ve stabilním stromě. Kdyby správci byli nuceni explicitně vybírat patche a odůvodňovat jejich zařazení do stabilního stromu, pak by podle něj všechny tři typy problémů byly vyřešeny.
První typ – patche, které samy zanášejí chyby – asi nikdy nebude úplně odstraněn; tak to zkrátka při vývoji softwaru chodí. Každý, kdo se do debaty zapojil, odsouhlasil, že jakmile je chybná oprava odhalena, Greg má rychle udělat stabilní vydání bez tohoto patche, takže regrese mizí rychle. Mezi zbytečné patche patří ty, které jsou backportovány do jader předcházejících tomu, kde se původní chyba objevila; tomu by se dalo předejít zahrnutím více informací do seznamu změn. Posledním typem, na který Jiří upozornil – záhadné patche – jsou, jak se ukázalo, bezpečnostní opravy. Jiří (a ostatní) by byli rádi, kdyby bezpečnostní opravy byly v seznamu změn vyznačené, ale to se asi nestane; místo toho se pracuje na upozorňování distributorů na bezpečnostní opravy skrze neveřejné kanály.
Jinými slovy: i když se pravděpodobně budou dělat nějaké změny, nebudou až tak zásadní. Greg asi bude vybíravější ohledně toho, co do stabilního stromu přijme. Asi ale nikdy nebude tak tvrdý jako Linus. Konec konců, uživatelé stabilního stromu – distributoři i koncoví uživatelé – chtějí, aby se do něj opravy dostávaly. Stabilní řady jádra jsou jedním z největších úspěchů v procesu vývoje jádra; jakékoliv změny v tom, jak se vytvářejí, budou pravděpodobně malé. Z pohledu většiny z nás budou opravy proudit dál jako obvykle.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.