Jaderné noviny - 9. 7. 2008

21. 8. 2008 | Jirka Bourek | Jaderné noviny | 3086×

Aktuální verze jádra: 2.6.26-rc9. Citáty týdne: James Bottomley, Ted Ts'o, Andrew Morton. Citáty týdne, část druhá: flamewar o firmwarech. Současné vývojové jádro je... linux-next? Vícefrontové síťování. Začleněno vylepšené printk().

Obsah

• Aktuální verze jádra: 2.6.26-rc9
• Citáty týdne: James Bottomley, Ted Ts'o, Andrew Morton
• Citáty týdne, část druhá: flamewar o firmwarech
• Současné vývojové jádro je... linux-next?
• Vícefrontové síťování
• Začleněno vylepšené printk()

Aktuální verze jádra: 2.6.26-rc9

Současné vývojové jádro 2.6 je 2.6.26-rc9 vydané 5. července. Dost změn na to, abychom potřebovali další -rc, a seznam regresí se také nevyprazdňuje dostatečně rychle (pravděpodobně protože mnoho lidí včetně těch, kteří hlásí chyby, je na dovolené). Společně s opravami je v něm nový ovladač pro kamery, které implementují standardní USB video třídu. Dlouhý changelog obsahuje detaily.

V době psaní tohoto článku bylo po 2.6.26-rc9 začleněno několik desítek sad změn. Většinou jde o opravy, ale je tam také rozšíření printk(), které umožňuje použít řetězcové specifikátory vyšší úrovně; detaily vizte níže.

Současné -mm jádro je 2.6.26-rc8-mm1. Nedávné změny v -mm zahrnují patch MMU notifikátorů, novou funkci alloc_pages_exact() pro efektivnější velké alokace, spoustu ladění podle checkpatch.pl a sérii patchů, která končí souborem

revert-revert-revert-revert-linux-next-revert-bootmem-add-return-value-to-reserve_bootmem_node.patch

o kterém raději nechceme nic vědět.

Současné stabilní jádro 2.6 je 2.6.25.10 vydané 2. července. Mnoho různých oprav chyb v celém stromě. Všem uživatelům jádra 2.6.25 se opět SILNĚ doporučuje aktualizovat na toto vydání.

Citáty týdne: James Bottomley, Ted Ts'o, Andrew Morton

Problém je v tom, že SystemTap příliš výrazně netěžil z inovací vycházejících z komunity, protože v podstatě nemá komunitu. Problém v širším pohledu je v tom, že když v Red Hatu přebírali peníze, nemysleli na to, že tento projekt nemusí vygenerovat komunitu obvyklou filozofií "zveřejníme kód a ona se objeví". Výsledkem je to, co vidíme dnes: řinčící a k nehodě náchylný nástroj, který inženýry ze Sunu nutí psát otřepaná malá kázání o výhodách plánovaně politického operačního systému.

-- James Bottomley

Zamysli se nad nějakou špatností spáchanou HALem a skripty pro uspání-probuzení v uživatelském prostoru (a kolik komplexity bude potřeba kvůli náhodným XML fragmentům, které budou parsovány různými dbus pluginy) a řekni mi upřímně, jestli bys věřil těm dnešním autorům desktopových aplikací, kterým bys dal toto rozhraní k dispozici. Protože oni najdou nějaký zajímavý způsob, jak ho (zne)užít...

-- Ted Ts'o

Je docela zjevné, že lidé (tj. vrcholoví správci) dokonce ani netestují kompilací své vlastní věci poté, co jsou začleněny do linux-next. Říkáš (ale neposkytuješ o tom důkazy), že linux-next je příliš nestabilní na to, aby se proti němu dalo vyvíjet. A hádej proč? Protože lidé se rozhodli ho tak nechat.

-- Andrew Morton

Citáty týdne, část druhá: flamewar o firmwarech

Ani ne 15 minut poté, co David zaslal svou poznámku, máme již 11 hlášení; a to je jenom z -mm série patchů. Dokážete si představit to množství hlášení o chybě, kdybychom dovolili, aby to bylo dodáváno ve vydání z hlavní řady na kernel.org? Jedna dobrá věc, kterou jsme nyní definitivně prokázali, je, že jsou lidé, kteří stahují, překládají a snaží se sestavit -mm jádro :-)

-- Ted Ts'o

Externí firmware je z návrhu systém náchylný k chybám, dokonce i s verzováním. Ale když je přeložen a spojen s ovladačem, je to blbuvzdorné.

Co se týče samostatných technických důvodů, nikdy bychom od ovladače neodpojili tak kritickou komponentu, jako je firmware. Jediná věc, která od prvního dne pohání tyto transformace, jsou obavy z toho, jestli bychom nepřekročili zákony.

-- David Miller

Všechny způsoby změny zavádějí nějaké riziko, že se něco rozbije. V tomto případě jsem se jako obvykle pokusil být opatrný a vyhnout se regresím. Nejdůležitější částí byla zjevně snaha mít způsob, jak zahrnout firmware do statického jádra.

Když dojde na moduly, tak by stejný postup zavedl určité množství komplexnosti, která se nezdá být nutná -- jestliže dokážete nahrát moduly, pak máte uživatelský prostor a i pro firmware můžete použít hotplug. Obzvlášť vzhledem k tomu, že mnoho moderních ovladačů již teď vyžaduje, abyste to udělali, takže tomu uživatelé rozumí a nástroje jako mkinitrd si s tím dokáží poradit -- testováním MODULE_FIRMWARE() u modulů, které jsou vkládány, a automatickým přidáním odpovídajících souborů. [...]

Je potřeba zůstat střízlivý dost dlouho na to, aby člověk řekl 'Y', když je tázán, jestli chce zahrnout potřebný firmware do jádra. A dokonce jsme tuto volbu nastavili jako výchozí pro ty, kteří nedokáží zůstat střízliví dostatečně dlouho. (Neměli bychom jako výchozí příště zavést 'allyesconfig'?)

-- David Woodhouse

Současné vývojové jádro je... linux-next?

Jednou z výhod, kterou vývojovému procesu přinesl git (a předtím BitKeeper), je možnost vidět nejaktuálnější stav Linusova stromu do poslední sekundy. Takže každý vývojář, který chce vědět, jaký je nejnovější směr vývoje, může tento strom vzít a dělat patche tak, aby do něj sedly. Zdá se ale, že hodnota repozitáře hlavní řady je pro vývoj nižší, než byla dříve. Hlavní řada již není místo, kde se děje to hlavní.

Vezměme například tuto odpověď od Andrewa Mortona poté, co zjistil, že patch zaslaný do linux-kernel se mu nepřeloží:

Předpokládám, že tento patch byl vytvořen proti nějakému zastaralému jádru, jako je současné Linusovo z hlavní řady. Chlapi, teď máme nový vývojový strom.

Pokračoval tímto výrokem:

Co ale opakovaně vidím, jsou lidé, kteří radostně vytahují patche pro 2.6.27 vytvořené proti stromu 2.6.26, když máme krásný strom 2.6.27, proti kterému lze vyvíjet. Tyto dny jsou pryč, pánové.

Zdá se, že zpráva je jasná: vývojová práce by měla být postavena proti stromu linux-next místo proti jádru hlavní řady. Dělat práci tímto způsobem má zjevné výhody, patche vyvinuté proti linux-next by se měly během příštího začleňovacího okna začlenit čistě. Vývojáři budou při své práci zároveň testovat stromy ostatních, takže se chyby objeví dříve. A samozřejmě si Andrew nebude muset stěžovat na patche, které se mu nepodařilo přeložit, přinejmenším ne tak často.

Linux-next je ale poněkud podivná základna, na které stavět vývoj. Každý den je sestaven znovu z více než 100 subsystémových stromů, z nichž každý se může ze dne na den změnit. Linux-next je pohyblivý cíl bez konzistentní nebo koherentní historie. Strom linux-next je každý den zcela nové dílo s unikátní - a prchavou - historií.

Uvažujme vývojáře, který zakládá svou práci na vydání hlavní řady - řekněme 2.6.26-rc9. Práce tohoto vývojáře bude odvozena od specifického commitu ve stromě hlavní řady jádra, který je v tomto případě znám jako b7279469d66b55119784b8b9529c99c1955fe747. Historie od 2.6.26-rc9 je dobře definovaná a tato série patchů může být začleněna do jakéhokoliv jiného repozitáře, který také obsahuje 2.6.26-rc9; identita tohoto commitu je konzistentní a neměnná přes všechny repozitáře. S takovýmto vývojovým stromem je (relativně) jednoduché sledovat hlavní řadu a její postup a začlenit něčí práci, když přijde čas. Gitový strom založený na hlavní řadě stojí na pevných základech.

Není možné stejným způsobem založit strom na linux-next. Vývoj může začít na specifickém commitu, ale zítřejší linux-next už tento commit vůbec nemusí obsahovat. Různé stromy, ze kterých se linux-next skládá, postupují do linux-next z předchozího dne nezávisle, což může samo o sobě věci zkomplikovat. Proces skládání všech těchto stromů dohromady ale může zahrnovat úkoly jako přesunutí patche z jednoho stromu do jiného nebo opravení přechodných patchů, které něco rozbijí. Konečný výsledek je lepší ale za cenu změny základního bodu [rebase] těchto stromů. Změna základního bodu zcela přepíše historii vývoje a způsobí, že stará historie ze stromu zmizí. Tak série patchů založená na předchozí historii ztrácí své základy.

A, protože linux-next je každý den složen ze svých komponent, patch vyvinutý na základě linux-next může, když se do tohoto stromu integruje, být začleněn uprostřed této sekvence; jinými slovy patch bude začleněn do stromu, který se výrazně liší od stromu, na základě kterého byl patch vyvinut. Jak to řekl Stephen Rothwell, správce stromu linux-next:

Jednou nevýhodou způsobu, jakým funguje linux-next, je to, že protože je znovuvytvářen každý den, nelze na něm založit nic, co by do něj mělo být začleněno.

Další zajímavý aspekt vývoje v linux-next zahrnuje změny v API. Dlouhotrvající pravidlo ve vývoji jádra je, že interní jaderná rozhraní se mohou změnit, pokud je k tomu dobrý důvod, ale osoba, která změnu dělá, je povinna opravit všechen kód ve stromě, který je touto změnou poškozen. Jestliže je ale změna API zavedena do linux-next, vývojář jednoduše není schopen opravit žádný kód, který se do linux-next dostane z jiných subsystémových stromů. Jestliže vývojář dostane do těchto stromů patche reagující na změnu API, tyto stromy nebude možné sloučit a přeložit jádry, které tuto změnu postrádají - například s hlavní řadou. Změny v API se tedy jinými slovy ztěžují - což je situace, kterou někteří mohou ocenit.

Tohle všechno znamená, že změny v API musí být provedeny technikami, jako je vytvoření vrstev zpětné kompatibility; tyto vrstvy poté mohou být ve vývojovém cyklu nebo dvou odstraněny, když je přechod hotový. Nebo je možné změny rozdělit a přidat do individuálních subsystémových stromů; to nicméně může mezi jednotlivými stromy vést k zajímavým závislostem ohledně řazení. V některých případech vidíme, že změny v 2.6.27 jsou začleněny do 2.6.26 ve formě pahýlu, což je způsob, jak zajistit, aby se všechny kousky složily dohromady.

Potom je tu jednoduchá záležitost vývojářů, kteří mají rádi stabilní základnu, na které mohou stavět svůj kód. Strom linux-next, protože obsahuje velké množství relativně nového kódu, bude také obsahovat velký podíl nových chyb. Kvůli tomu jsou vývojáři, kteří mají často problémy vychytat své vlastní chyby, poněkud nevrlí. Vývoj proti hlavní řadě mívá nižší pravděpodobnost, že bude vývojář nucen hledat chyby, které nejsou jeho dílem.

Na mnoho těchto stížností je jednoduchá odpověď: nepříjemnostem, které pocházejí z toho, že se všechny kousky skládají dohromady v linux-next, je stejně nutné někdy čelit. Skutečným rozdílem je, že linux-next umožňuje řešit tyto problémy ve volném čase, zatímco starší model "začlenit všechno do hlavní řady" stlačil většinu této práce do začleňovacího okna. Jak prospěšné to skutečně bude, se poprvé uvidí během začleňovacího okna 2.6.27; jestliže linux-next poslouží svému záměru, 2.6.27 by se měl poskládat s poněkud menšími hádkami než jeho bezprostřední předchůdci.

Bez ohledu na hodnotu, kterou linux-next poskytuje pro účely integrace a testování, ale zůstává faktem, že je to obtížná platforma, na které vyvíjet patche. Ten proces je trochu podobný stavbě domu na písčitých základech; přes noc přijde příliv a úplně změní zem pod vámi. To je důvod, proč je většina (pravděpodobně všechny) subsystémových stromů, které se skládají v linux-next, založena na hlavní řadě.

Řešení tohoto problému se bude muset vyvinout časem. Linux-next je nová instituce, která si stále hledá své správné místo ve vývojovém procesu. Na jednodušší způsoby, jak vyvinout patche proti stromu linux-next, se určitě přijde; může se snadno ukázat, že nástroje jako quilt se s tímto úkolem vypořádají lépe než git. Nicméně v současnosti je linux-next excelentní zdroj pro integraci a testování, který se ale ještě nezvládl stát skutečným linuxovým vývojovým stromem.

Vícefrontové síťování

Jednou z klíčových datových struktur v síťovém subsystému je odesílací fronta spojená s každým zařízením. Jádro síťového kódu volá funkci ovladače hard_start_xmit(), aby dalo ovladači vědět, že je paket připraven k odeslání; úkolem ovladače je poté přesunout tento paket do odesílací fronty hardwaru. Výsledkem je datová struktura, která vypadá přibližně takto:

"Přibližně", protože seznam struktur sk_buff (SKB - interní reprezentace paketu) v této formě v jádře neexistuje; místo toho ovladač udržuje frontu tak, aby ji byl hardware schopen zpracovat.

Toto schéma fungovalo léta, ale narazilo na významné omezení: nenamapuje se dobře na zařízení, která mají více odesílacích front. Taková zařízení jsou čím dál tím běžnější obzvláště v oblasti bezdrátového síťování. Například zařízení, která implementují Bezdrátová multimediální rozšíření [Wireless Multimedia Extensions], mohou mít čtyři různé třídy služeb: video, hlas, největší snaha a na pozadí [video, voice, best-effort, and background]. V rámci zařízení může provoz videa a hlasu obdržet vyšší prioritu - jsou odeslány první - a zařízení může pro tyto pakety také vyhradit více vysílacího času. Na druhou stranu fronty pro tento druh provozu mohou být relativně krátké; jestliže se paket s videem nepodaří odeslat rychle, přijímací strana o něj ztrácí zájem a jde dál. Proto může být lepší prostě video pakety, které byly příliš zpožděny, zahodit.

Na druhou stranu úroveň "na pozadí" se k odesílání dostane jenom v případě, že není nic jiného na práci; je dobře přizpůsobena pro provoz nízké úrovně, jako je například bittorrent nebo e-mail od šéfa. Mělo by však smysl mít relativně dlouhou frontu pro pakety na pozadí, aby se daly plně využít pauzy provozu s vyšší prioritou.

Uvnitř těchto zařízení má každá třída služby svou vlastní frontu. Oddělení provozu hardwaru zjednodušuje výběr toho, který paket poslat jako další. Také to umožňuje nezávislé limity na velikost každé fronty; nemá smysl plnit do prostoru fronty v zařízení provoz na pozadí, který stejně nebude odeslán. Síťový subsystém ale nemá pro zařízení s více frontami zabudovanou žádnou podporu. Hardware je nucen k použití mnoha kreativních technik k tomu, aby se to stalo, což není optimální. To se ale může změnit s příchodem série patchů pro vícefrontové odesílání od Davida Millera.

Současný kód považuje síťové zařízení za základní jednotku, která je řízena plánovačem odchozích paketů. Davidovy patche toto uspořádání mění, protože každá odesílací fronta musí být plánována samostatně. Proto je zde nová struktura netdev_queue, která obsahuje všechny informace o jedné odesílací frontě a která je chráněna vlastním zámkem. Vícefrontové ovladače potom mohou nastavit pole těchto struktur. Nová datová struktura může s dostatkem představivosti vypadat nějak takto:

Skutečný seznam odchozích paketů opět existuje ve formě speciálních datových struktur v paměti přístupné pro zařízení. Jakmile má zařízení tyto fronty pro sebe nastavené, lze implementovat různé politiky spojené s každou třídou služby. Každá fronta je spravována nezávisle, takže lze zařadit více hlasových paketů, i když nějaká jiná fronta (řekněme "na pozadí") přetéká.

Zdá se, že si David dával velký pozor, aby nezpůsobil problémy vývojářům síťových ovladačů. Ovladače pro zařízení s jednou frontou není vůbec potřeba měnit a přidání podpory pro více front je relativně přímočaré. Prvním krokem je nahradit volání alloc_etherdev() voláním:

struct net_device *alloc_etherdev_mq(int sizeof_priv, 
                                     unsigned int queue_count);

Nový parametr queue_count popisuje maximální počet odesílacích front, které může zařízení podporovat. Skutečný počet těch, které se používají, by měl být uložen v poli real_num_tx_queues struktury net_device. Všimněte si, že tuto hodnotu lze změnit, pouze když je zařízení vypnuté.

Vícefrontový ovladač obdrží pakety určené pro libovolnou frontu obvyklou funkcí hard_start_xmit(). Aby určil, která fronta se má použít, měl by ovladač zavolat:

u16 skb_get_queue_mapping(struct sk_buff *skb);

Návratová hodnota je index v poli odesílacích front. Dalo by se pozastavit nad tím, jak jádro síťování vlastně rozhodne, kterou frontu použít. To se řeší pomocí nového callbacku net_device:

u16 (*select_queue)(struct net_device *dev, struct sk_buff *skb);

Sada patchů zahrnuje implementaci select_queue(), kterou lze použít v zařízeních zvládajících WME.

Jediná další potřebná změna je, že vícefrontové ovladače musí informovat jádro síťování o stavu specifických front. K tomu účelu je nová sada funkcí:

struct netdev_queue *netdev_get_tx_queue(struct net_device *dev,
                                         u16 index);

void netif_tx_start_queue(struct netdev_queue *dev_queue);
void netif_tx_wake_queue(struct netdev_queue *dev_queue);
void netif_tx_stop_queue(struct netdev_queue *dev_queue);

Volání netdev_get_tx_queue() vrátí index fronty pro ukazatel struct netdev_queue potřebný pro ostatní funkce, které mohou být použity k zastavení a nastartování fronty obvyklým způsobem. Kdyby ovladač potřeboval pracovat se všemi frontami naráz, je zde sada pomocných funkcí:

void netif_tx_start_all_queues(struct net_device *dev);
void netif_tx_wake_all_queues(struct net_device *dev);
void netif_tx_stop_all_queues(struct net_device *dev);

Přirozeně je zde pár dalších detailů, které je potřeba vyřešit, a rozhraní pro vícefrontová zařízení se pravděpodobně bude časem trochu vyvíjet. V jednu chvíli David doufal, že bude mít tuto vlastnost připravenou pro začlenění do 2.6.27, ale tento cíl se nyní zdá příliš ambiciózní. Vypadá to, že mnoho ze základní práce bude v příštím vývojovém cyklu začleněno, což znamená, že plná podpora pro více front by měla být v dobrém stavu pro začlenění do 2.6.28.

Začleněno vylepšené printk()

Velmi pozdní změna ve vývojovém cyklu 2.6.26 poskytuje framework pro rozšíření printk(), aby zvládalo nové druhy argumentů. Linus Torvalds změnu právě začlenil - po -rc9 - pravděpodobně částečně proto, že ví, že autorovi může věřit, ale také protože by neměla mít na jádro žádný vliv. Lepší ladící výstup poskytne, až se změní kód, aby ji mohl využít.

Jádrem tohoto nápadu je rozšířit printk() tak, aby mohly být jaderné datové struktury formátovány způsobem specifickým pro jádro. Kvůli možnosti provádět nějaké ověřování v době překladu byl specifikátor formátu %p přetížen. Například lze využít %pI, kterým se ukáže, že je spojený ukazatel formátován jako struct inode, což by mělo vypsat ta nejzajímavější pole této struktury. GCC bude schopné ověřit přítomnost parametru ukazatel, ale protože nebude rozumět té části s I, nebude moci vynutit ukazatel správného typu.

Rozšíření printk() tímto způsobem umožňuje Linusovi - který patch napsal - přidat printk() dva nové typy: %pS pro symbolické ukazatele a %pF pro symbolické ukazatele na funkce. V obou případech kód používá kallsyms, aby změnil hodnotu ukazatele na jméno symbolu. Místo toho, aby musel jaderný vývojář číst dlouhé řetězce adresy a potom je hledat v systémové mapě, jádro tuto práci udělá za něj.

Specifikátor %pF je pro architektury jako ppc a ia64, které místo ukazatelů používají popisovače funkcí. Pro tyto architektury ukazatel na funkci ukazuje na strukturu, která obsahuje skutečnou adresu funkce. Použitím specifikátoru %pF se provede správné dereferencování.

Jako příklad, jak může být rozšířená funkce printk() použita, Linus konvertoval printk_address(). Závislosti na CONFIG_KALLSYMS a kallsyms_lookup() byly odstraněny, čímž v podstatě vznikla jednořádková funkce:

printk(" [<%016lx>] %s%pS\n", address, reliable ? "": "? ", (void *) address);

Jestliže není kallsyms přítomna, nová printk() se prostě vrátí k vypsání adresy v hexadecimální formě, což umožňuje, aby ošetření speciálních případů proběhlo tam.

Zjevným záměrem je umožnit dalším rozšířením printk() podporovat další jaderné struktury. Změna ve vsprtinf(), která je na printk() vázaná, ve skutečnosti umožňuje, aby se za %p objevila jakákoliv sekvence alfanumerických znaků. Nová pomocná funkce pointer() v současnosti implementuje pouze dva nové specifikátory, ale byly zmíněny i jiné.

Nejpravděpodobnější rozšíření jsou pro věci, jako jsou IPv4, IPv6 a MAC adresy. Linus specificky zmiňuje použití %p6N jako možnost pro IPv6 adresy. Někteří by raději viděli použití jiné syntaxe, bylo navrženo %p{vlastnost}, ale to by bylo v konfliktu s jinými současnými použitími %p v jádře. Linusovi se tato volba líbí:

Úmyslně jsem vybral '%p[alfanumerické]*', protože je v podstatě zcela šílené mít to ve skutečném printk() řetězci: konečný výsledek by byl zcela nečitelný.

Patch se do jádra dostal zajímavou cestou, většina diskuze evidentně proběhla soukromě mezi Linusem, Andrewem Mortonem a dalšími předtím, než se objevila na mailových konferencích linuxppc-dev a linux-ia64. Patch sám nebyl zaslán v kompletní formě do linux-kernel, ale byl začleněn 6. července. I když je poněkud podivné vidět takovou změnu tak pozdě ve vývojovém cyklu, je to změna, která by neměla mít žádný dopad, protože v 2.6.26 nejsou žádné plány na skutečné použití těchto nových specifikátorů.

       

Komentáře

[zde]

PPC popisovače funkcí (co je mi známo) nepoužívá. Nemělo tam být PPC64?

[trekker.dk]

V originále je PPC.

[zde]

Komentáři ve zdrojáku bych věřil víc.

lib/vsprintf.c:
* The difference between 'S' and 'F' is that on ia64 and ppc64 function
* pointers are really function descriptors, which contain a pointer the
* real address.