Portál AbcLinuxu, 6. května 2025 04:20
Aktuální verze jádra: 2.6.33-rc1. Citáty týdne: Alan Cox,. pr_nechceme(). Turbulence pro pracovní fronty řízené souběžností. Dva, kteří to nezvládli (AlacrityVM a CephFS).
Současné vývojové jádro je 2.6.33-rc1 vydané Linusem 17. prosince. Začleňovací okno 2.6.33 je nyní uzavřené; mezi významné patche začleněné od shrnutí z minulého týdne patří ovladač pro přímé vykreslování na virtuálním GPU VMware společně s ovladači pro:
Od vydání 2.6.33-rc1 bylo začleněno malé množství patchů; mezi opravami je také sada patchů přepracovávající API kfifo.
Stabilní aktualizace: 18. prosince byly vydány aktualizace stabilních jader 2.6.27.42, 2.6.31.9 a 2.6.32.2. Všechny obsahují dlouhý seznam oprav v celém stromě jádra.
-- Alan Cox
Jedním z nejlepších přátel jaderného vývojáře je funkce printk(), která funguje podobně jako printf() v programech pro uživatelský prostor. Jsou zde ale jisté rozdíly, mezi které patří různé úrovně logování. Používaná konvence je poměrně směšná v tom, že úroveň logování je krátký řetězec připojený před formátovací řetězec. Varování lze tedy vypsat například takto:
printk(KERN_WARNING "Hrozí roztavení jádra\n");
Tato podoba nicméně není univerzálně oblíbena; někteří říkají, že je příliš upovídaná, což ztěžuje snahu udržet řádky pod 80 sloupci délky, a na řetězec identifikující vážnost je snadné zapomenout. Jako alternativy k těmto funkcím se jádro 2.6.28-rc5 dočkalo maker pr_*(), která napsal Martin Schwidefsky a která mají lidem zjednodušit život. Varování výše by proto bylo možné přepsat takto:
pr_warning("Detekovány softwarové patenty\n");
Několik vývojových cyklů se tato makra příliš nepoužívala, dokud se Joe Perches nerozhodl změnit několik příkazů printk() ve vnitřních částech jádra. To vedlo k výlevu Petera Zijlstry a nakonec k vrácení změny zpět. Peter říká:
Je velká šance, že v této části jádra u žádné takové konverze nebudou. Makra pr_*() ale nezmizí. Jejich skutečný účel pravděpodobně nejlépe vyjádřil Arjan van de Ven: pr_ je ve skutečnosti jenom pro ,Já jsem ovladač a chci vypsat jednořádkovou zprávu ve standardizovaném formátu‘. Na tom není nic špatného.
Souběžností řízené pracovní fronty [concurrency-managed workqueues] Tejuna Heo zde byly diskutovány v říjnu. Práce na nich pokračuje a některé s tím spojené pročišťovací patche byly začleněny do 2.6.33; hlavní část práce je pravděpodobně na cestě k začlenění do 2.6.34. A nebo možná ne: Někteří vývojáři začínají mít pochybnosti.
Nejhlasitější stížnosti pocházejí od Petera Zijlstry, který by byl raději, aby se tato snaha zaměřila na konverzi uživatelů pracovních front a k používání obsluh přerušení ve vláknech. Vývojářům, jako je Peter, se nové pracovní fronty zdají být zdrojem nové složitosti, která by mohla vytvořit nové problémy (například se správou úloh náročných na CPU v pracovních frontách) a přitom nevyřešit staré, mezi než patří problémy se zamykáním, jež mohou uživatelům pracovních front způsobit potíže nyní.
Tejun zareagoval popisem některých problémů, které byly přepracovanými pracovními frontami vyřešeny. Jeho závěr:
V tom by ale mohl být ten problém: Sada patchů ve svém současném stavu nijak nedemonstruje tento přesun složitosti. Ingo Molnár proto požádal o nějakou ukázkovou konverzi, která by ukázala výhody souběžností řízených pracovních front:
Tejun naznačil, že zapracuje na nějaké demonstraci. Pokud by další verze patche byla na této frontě přesvědčivá, nové pracovní fronty by mohly být zpět na cestě do 2.6.34.
Začleňovací okno 2.6.33 je za námi a do hlavní řady byla začleněna spousta kódu. Začleňovací okno se však podobá hře s hudbou a židlemi: Když přestane hrát hudba, vždycky zůstane jeden viditelný projekt, který si nemá kam sednout. Tentokrát židle nezbyla na dva projekty, přestože bylo žádáno o jejich přetažení: distribuovaný souborový systém Ceph a kód hypervizoru AlacrityVM.
Původci ignorovaných požadavků na přetažení kódu jsou často v tichosti opominuti a nedozví se, proč jejich požadavku nebylo vyhověno. Tentokrát Linus nepřetažení vysvětlil: Podle něj o tyto vlastnosti není dostatečný zájem. Jeho slovy:
CEO Sunu Scott McNealy kdysi řekl, že svobodný software je jako štěně zdarma. Na této poznámce je obecně něco pravdy a u kódu přetahovaného do jádra to platí hodně. Kód sám o sobě je zadarmo a je k němu připojena hezká GPL-kompatibilní licence. Jaderní vývojáři ale ví, že jim takový kód předtím, než bude správně vytrénován, nechá na koberci několik překvapení a sežere oblíbené pantofle. Také je potřeba ho krmit a po několik let občas vodit k veterináři, takže je nutné se ujistit, že takové štěně uživatelé opravdu chtějí. Proto Linus uživatele žádá, aby svou podporu pro nové vlastnosti dávali najevo.
Získat takovou podporu ale může být situace podobná Hlavě 22. Je potřeba sehnat dostatečně odhodlaného uživatele, aby vzal patch, na kterém se pracuje, a přidal si ho do jádra; to většina uživatelů neudělá. Život je jednodušší, když distributoři navrhovaný kód přibalí a dají tak uživatelům šanci ho vyzkoušet bez nutnosti překládat a instalovat nové jádro; za to se ale mohou dostat do potíží. Nedávné dění ohledně Nouveau bylo krásným příkladem nespokojenosti z toho, že někdo dodává kód mimo strom. Podobně jako před několika lety, když SUSE dodávalo AppArmor bez předchozího začlenění, což vedlo na tuto stížnost Andrewa Mortona:
Přimět zákazníky k tomu, aby software vyžadovali – a byli přitom Linusu Torvaldsovi na doslech – aniž by daný software byl předtím začleněn nebo dodán, však občas může vypadat poměrně složitě.
Přinejmenším jeden veřejný požadavek o začlenění Ceph v příštím vývojovém cyklu se objevil. Pro AlacrityVM může ale laťka být vyšší – nezdá se, že by někde byl dav uživatelů, kteří chtějí novou sadu ovladačů virtualizovaných zařízení, která se mají používat s virtualizačním mechanismem mimo strom. Krom toho minulé diskuze o tomto kódu byly dlouhé a rozvášněné, přičemž mezi vývojářem AlacrityVM Gregory Haskinsem a (hlavně) vývojáři KVM panují výrazné neshody.
Tato historie vedla Inga Molnára k tomu, že připomněl dřívější flamewary a žádal Gregoryho, aby se více snažil o spolupráci s vývojovou komunitou KVM. Není třeba říkat, že to vedlo k další rozsáhlé diskuzi, ve které Gregory prohlásil, že se opravdu snažil pracovat s ostatními vývojáři a že v každém případě současné zaslání AlacrityVM, které se skládá hlavně z ovladačů, není pro KVM relevantní. Odtud se diskuze posunula k tomu, jestli je tato práce skutečně zapotřebí, o nejlepších přístupech k tomu, jak zlepšit I/O výkonnost virtualizovaných hostů, atd.
Není jasné, jestli existuje jiné zjevné řešení této konkrétní neshody, než přimět uživatele pořádně vyzkoušet různá řešení a ohlásit, co funguje nejlépe. Pro virtualizační řešení mimo strom to bude těžké, ale existence takovéto kontroverze začlenění ztíží ještě více. O tom se Linus vyjádřil poměrně jasně:
Kód byl vyvinut v SUSE, které pravděpodobně chce poskytnout AlacrityVM svým zákazníkům. Může jít o jednu ze situací, kdy distributor nebude mít jinou možnost, než dodávat kód před začleněním do hlavní řady, aby se mu dostalo zpětné vazby od uživatelů, která ukáže, že to stojí za to. To má samozřejmě rizika: Kód nikdy nemusí být začleněn nebo později může na své cestě do hlavní řady trpět nekompatibilními změnami. Alternativou nicméně může být to, že se kód bude navždy válet na kraji cesty.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.