Jaderné noviny – 23. 12. 2009

22. 1. 2010 | Jirka Bourek | Jaderné noviny | 2520×

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).

Obsah

• 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

Aktuální verze jádra: 2.6.33-rc1

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:

• regulátory napětí Maxim 8660/8661,
• PMIC zařízení Marvell 88PM8607,
• akcelerometry ST Microelectronics LIS3LV02Dx,
• NAS desky LaCie Network Space v2,
• SPI řadiče DesignWare,
• SPI řadiče série Samsung S3C64XX,
• MDIO sběrnice pro systémy na čipu Octeon,
• řadiče pro ethernetový port pro správu Octeon,
• platformy Cisco PowerTV a
• SCSI řadiče HP Smart Array.

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.

Citáty týdne: Alan Cox,

A jako bonus navíc do svých stížností přidej něco, co bude dobře citovatelné a vtipné, pak se dostaneš i do Jaderných novin.

-- Alan Cox

Pro překlad jádra potřebujeme nějaký rozumný skriptovací jazyk. Vezměte si problémy, které máme s různými verzemi nebo někdy dokonce s různými překlady sh, awk a dokonce i bc – plus fakt, že tyto nástroje nemusí nutně dělat to, co potřebujeme, je velmi frustrující. Osobně si myslím, že závislost na Perlu je lepší než ten chaos, ve kterém jsme teď; chápu, že někteří lidé se mnou souhlasit nebudou. Co ale rozhodně není akceptovatelné, je status quo. Upřímně je současná situace tak praštěná, že by možná bylo nejlepší napsat malý skriptovací engine a dodávat ho s jádrem.

-- H. Peter Anvin

Dvoutýdenní začleňovací okno není míněno jako „jednodenní začleňovací okno po třinácti dnech ticha“. Ve skutečnosti bych řekl, že příště bude mít začleňovací okno jenom 11-12 dní a lidi, kteří se pokusí oblafnout systém a vytvořit požadavek na přetažení na poslední chvíli, se dočkají nepříjemného překvapení a nenuceného postrčení do 2.6.35.

-- Linus Torvalds

pr_nechceme()

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á:

Možná jsem divnej, ale když chci v C něco vypsat, použiju print[fk]() a tím mám hotovo, není žádný důvod zavádět kvůli tomu nějaké pitomosti. Snažíme se držet ANSI-C tak moc, jak je to možné, máme kalloc, kfree, strcmp, strnlen a všechny další ,běžné‘ kousky C, odklonit se od toho nemá žádný smysl a vede to ke zmatkům.

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.

Turbulence pro pracovní fronty řízené souběžností

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:

Přesun komplexity mimo periferní kód někam do lépe připraveného a spravovaného centra je správná věc, z periferního kódu tím složitosti mizí.

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:

U této konkrétní sady patchů by mělo být možné identifikovat existující vzory kódu v kódové základně ovladačů, která má 6+ milionů řádek, a ukázat na nich výhody těchto 2000+ řádků vnitřního jaderného kódu. U současných abstrakcí je hlášeno několik problémů – určitě tedy musí být způsob, jak nový kód na některých místech předvést.

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.

Dva, kteří to nezvládli

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:

Nejlepší, co lze udělat, je snažit se přesvědčit uživatele, aby se o vlastnosti vyjadřovali a mluvili o tom, jak je skvělá. Jinými slovy, aby se za ni přimluvili. I hrstka lidí, kteří řeknou „hej, tohle používám a je to skvělé“, pro mě znamená hodně. U alacrityvm a cephfs jsem nic takového neměl nebo ti lidé prostě jenom nebyli dostatečně hlasití.

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:

Ach jo. Nestavte nás prosím zase do téhle pozice. Nejdřív věci začleňte do upstreamu a pak ho teprve dodávejte zákazníkům, OK? Tak těžké to není.

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ě:

Takže když uvidím další virtualizační rozhraní, chci, aby si to lidé od virtualizace vyřídili mezi sebou. Vzhledem k tomu, že se o virtualizaci ani v nejmenším nezajímám, můžu klidně stát opodál a pozorovat ohňostroj.

Tím neříkám, že si to budu užívat. (Mám rád občasný flamefest, ale aby se mi líbil, muselo by mě to zajímat natolik, abych se pro to zapálil!) Jenom prostě nechci, aby se v mém stromě bojovalo, takže radši vidím, když se bojování vyřídí předtím, než něco přetáhnu.

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.

       

Komentáře