Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře

1. 10. 2012 | Luboš Doležel

Články - Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře  

Aktuální verze jádra: 3.6-rc5. Citáty týdne - pohled zvenčí. Jaderný summit 2012: Údržba stabilních jader; Lepší trasování a ladění; Zlepšování vývojového procesu: linux-next.

Obsah

• Aktuální verze jádra: 3.6-rc5
• Citáty týdne - pohled zvenčí
• Jaderný summit 2012
  • Údržba stabilních jader
  • Lepší trasování a ladění
  • Zlepšování vývojového procesu: linux-next

Aktuální verze jádra: 3.6-rc5

Aktuální vývojová verze jádra je 3.6-rc5 vydaná 8. září. Tak nám vyšlo 3.6-rc5 a všechno vypadá docela v klidu. Až moc, abych pravdu řekl; čekám, kdy se to rozjede, kdy se Greg konečně probere svým mailboxem po jaderném summitu a výletu na kajaku. Mám podezření, že i pár dalších vývojářů bylo potichu kvůli jadernému summitu a cestování s tím spojeným.

Stabilní aktualizace: verze 3.2.29 vyšla 12. září s obvyklou dávkou důležitých oprav.

Citáty týdne – pohled zvenčí

Tohleto není mailing list linux-kernel; tady nemáte právo chovat se neomaleně jen kvůli tomu, že máte špatnou náladu, nesouhlasíte s něčím uvažováním nebo jste omylem vypili kafe bez kofeinu.

-- Bryan O'Sullivan

Práva k jadernému kódu samozřejmě patří jaderným vývojářům, kteří aktivně podkopávají vynucování těchto práv. O to tu ale nejde; mají na to právo, i když je to frustrující.

Morální práva ke kódu zase na druhou stranu patří každému, kdo, kdyby GPL bylo u jádra náležitě vynucováno, by měli právo získat a používat tento kód, který by jim umožnil používat hardware dříve na Linuxu nepodporovaný.

-- Rich Felker

Jaderný summit 2012

Údržba stabilních jader

V krátkém shromáždění ke konci prvního dne Jaderného summitu 2012 vyjádřil Greg Kroah-Hartman, který se aktuálně stará o stabilní jádra, své obavy o stabilní jádra, a odpovídal na otázky přítomných.

Greg řekl, že si může stěžovat jen na jednu věc: subsystémy, které neoznačují patche za vhodné pro stabilní řadu. Greg zmínil několik takových subsystémů a současně pochválil Dava Millera za to, že odvádí spoustu náročně práce v síťování. Greg pak vyslechl názory ostatních lidí.

Ted Ts'o poznamenal: Rád bych označoval některé méně urgentní patche jako 'odložené-stabilní' (stable-deffered), abych je v případě výskytu regresí mohl odvolat. Greg řekl, že se pokusí tuto funkci implementovat, protože to je dobrý nápad.

Několik lidí chtělo lépe porozumět kritériím, která určují, jestli má patch být zaslán do stabilní řady, někteří poukázali na to, že Greg má v tom, co se považuje za přijatelný patch, trochu nepořádek. Greg toto uznal s tím, že důvěřuje správcům subsystémů, aby rozhodli, co se má zaslat do stable@bger.kernel.org. Co se týče rozhodování, co se má poslat do stable, pochopitelně připomenul Documentation/stable_kernel_rules.txt a shrnutí odůvodnění stable: pokud by patch mohl být zajímavý pro distribuce, které chtějí dodávat stabilní jádro, tak by patch měl být zaslán do stable.

James Bottomley řekl, že má spoustu patchů pro SCSI, které nejde na stabilní jádro aplikovat, takže z nich odstraňuje tag stable. Zeptal se, co se má v takovém případě dělat?; Greg odpověděl, že by měl tag stable ponechat a pak odpovědět na automatizovaný e-mail, který dostane poté, co se nepodaří patch aplikovat na stabilní strom, se správnou cestou ke staršímu stromu.

Greg setkání uzavřel otázkou, jestli je současné tempo vydávání stabilních řad v pořádku. Lidé se obecně shodli, že současné tempo – vydání jednou za týden nebo dva – je dobré a mnoho jich také ocenilo, jakou výbornou práci Greg odvádí.

Lepší trasování a ladění

Během prvního dne Jaderného summitu proběhla diskuze o zlepšování trasování a ladění jádra pod taktovkou Jasona Wessela a Stevena Rostedta. Jason se zajímal hlavně o to, jak od uživatelů, kteří posílají hlášení o pádu jádra, dostávat lepší údaje.

Většina diskuze se točila kolem Jasonova návrhu na změny v jádře, které by umožnily, aby součástí backtrace z pádu jádra byla čísla řádek ze zdrojových souborů, aby bylo původ pádu snadnější identifikovat. Navrhovaná technika je implementovaná zahrnutím tabulek ELF s potřebnými informacemi do kompilovaného jádra. S Jasnovým patchem je používání této funkce přímočaré: jádro je konfigurováno s CONFIG_KALLSYMS_LINE_LOCATIONS a kompilováno s ladící informací. Jakmile je to hotové, tak situace jako paniky jádra generují backtrace včetně názvů zdrojových souborů a čísel řádek:

    Call to panic() with the patch set
    ----------------------------------
    Call Trace:
     [<ffffffff815f3003>] panic+0xbd/0x14 panic.c:111
     [<ffffffff815f31f4>] ? printk+0x68/0xd printk.c:765
     [<ffffffffa0000175>] panic_write+0x25/0x30 [test_panic] test_panic.c:189
     [<ffffffff8118aa96>] proc_file_write+0x76/0x21 generic.c:226
     [<ffffffff8118aa20>] ? __proc_create+0x130/0x21 generic.c:211
     [<ffffffff81185678>] proc_reg_write+0x88/0x21 inode.c:218
     [<ffffffff81125718>] vfs_write+0xc8/0x20 read_write.c:435
     [<ffffffff811258d1>] sys_write+0x51/0x19 read_write.c:457
     [<ffffffff815f84d9>] ia32_do_call+0x13/0xc ia32entry.S:427

Lepší backtrace poskytovaný těmito patchi bezpochyby usnadní diagnostiku některých pádů jádra. Má to ale i stinnou stránku: objem paměti spotřebované takovým jádrem je větší. Během diskuze bylo zmíněno číslo 20 MB, ačkoliv v později zaslaném e-mailu Jason upřesnil, že se jedná spíše o 10 MB.

Značné zvýšení spotřeby paměti jako následek Jasonovy techniky hned vedlo ke skepticismu ostatních, co se užitečnosti týče. Jak někdo poukázal, takové zvýšení by jistě neuvítali uživatelé, kteří jádro provozují například na virtuálních strojích na službách jako Amazon EC2, kde je dostupná paměť (například) omezena na 0,5 GB. Jiní zase řekli, že by pravděpodobně bylo možné dosáhnout toho samého přes vhodně sestavené jádro, které by bylo v případě pádu spuštěno přes kexec(). (Ale i tento nápad byl zpochybňován, neboť i tato technika by mohla vést ke značné paměťové režii.)

Pak se do debaty vložil Linus, který s návrhem také nesouhlasil. Podle jeho názoru představují paniky jádra natolik malý podíl chybových hlášení, že jsou náklady tohoto řešení neopodstatněné; 1 MB režie by ale byl přijatelý. Linus dále řekl, že při troše snahy by mělo být možné získat podobný traceback načtením jádra do GDB.

I když patche navrhované Jasonem poskytují užitečné zlepšení v ladění, tento přístup se setkal s takovým odporem, že je nepravděpodobné, že by cokoliv v této podobě bylo kdy začleněno. Jason se ale dost možná ještě nevzdal. V později poslaném e-mailu uvažoval o úpravách, které by mohly srazit využití paměti na nějakých 5 MB, stejně tak o dalších technikách, které by se mohly využít k tomu, aby měl uživatel větší kontrolu nad tím, kdy je tato funkce nasazena v běžícím jádře. Proto je možné, že se tento nápad v nějaké jiné podobě objeví později.

Zlepšování vývojového procesu: linux-next

Dalším tématem ke konci prvního dne Jaderného summitu 2012 byl strom linux-next a případný doplňující strom.

Steven Rostedt řekl, že by rád viděl strom „linux-devel“, který by měl podobný účel, jako měl kdysi strom „-mm“ Andrewa Mortona: bylo by to místo, kde by se rozumně stabilnímu kódu dostalo dalšího testování. Dále řekl, že by takový strom mohl být užitečný kupříkladu pro API, která ještě nebyla stabilizována. Steven se zeptal ostatních, zda i je by cosi takového zajímalo.

Chris Mason měl pochyby o tom, jestli by takový strom vůbec v praxi fungoval. Když se má a tvá práce spojí dohromady, tak lidé viní mě za tvé chyby a naopak. Na základě zkušeností s podobným přístupem z jiného projektu Ben Herrenschmidt ukázal na další problém: lidé začnou vyvíjet kód proti tomuto stromu namísto proti k tomu určenému stromu (vytvoření linux-devel by mohlo zapříčinit, že lidé začnou vyvíjet proti němu místo linux-next). Tony Luck řekl, že význam linux-devel by se odvíjel podle toho, kolik testování by se mu skutečně dostalo a odhad lidí byl takový, že by se mu dostalo testování ještě méně než linux-next, kterému by se také jistě hodilo testování více.

I kdyby se došlo k názoru, že linux-devel za tu námahu stojí, bylo by mu třeba najít správce. Na otázku, kolik práce je třeba pro údržbu linux-next, se ozval Stephen Rothwell, že je třeba mezi čtyřmi až deseti hodinami denně, v závislosti na aktuální fázi vývojového cyklu. Steven Rostedt nakonec sám uznal, že reakce na ideu stromu linux-devel byla nedostačující.

Pozornost se pak přesunula k linux-next. Ted Ts'o se zeptal: jsou lidé spokojení s tím, jak strom funguje? Lidé se shodli, že funguje dobře. H. Peter Anvin to shrnul svým vlastním názorem, že nedokonalosti linux-next jsou odrazem skutečnosti, že jde o výtvor ze skutečného světa. Ted se pak přítomných zeptal – a zjevně očekával odpověď NE – používá někdo z vás linux-next na svém vývojovém systému? a docela ho překvapilo, že značné množství přítomných vývojářů používá své vlastní dílo každý den. Po více než třech letech je jasné, že se linux-next stal důležitou součástí vývojového modelu jádra.

Diskuse k tomuto článku

[Pev]

objem paměi spotřebované takovým jádrem je větší Díky za překlad.

[Pev]

&bso; =>  

[Michal Kubeček]

pochopitelně připomenul Documentation/stable_kernel_rules.txt

Když se podívám, co všechno jde do stable větví, nemám pocit, že by tahle pravidla ještě někdo bral vážně…

[mirec]

Iba mne druhý citát pripomenul nášho prezidenta, budem citovať:

„Na druhej strane si myslím, že Slovensko niekedy, žiaľbohu, a niekedy je to aj chvalabohu, že žiaľbohu, že na Slovensku predsa len tá pracovná sila je ešte stále lacnejšia a teraz, chvalabohu, že je lacnejšia."

[Bedňa]

Ja už chválabohu niekoľko rokov nesledujem politiku, pretože mi to žiaľbohu prišlo zbytočné.

[Jindřich Makovička]

Hm, Riche Felkera si pamatulu z MPlayer mailing listu, a vždycky to byl tak trochu magor. Občas mu zdatně sekundoval Ivan Kalvachev.

[D.A.Tiger]

...Lepší backtrace poskytovaný těmito patchi bezpochyby usnadní diagnostiku některých pádů jádra. Má to ale i stinnou stránku: objem paměi spotřebované takovým jádrem je větší. Během diskuze bylo zmíněno číslo 20 MB, ačkoliv v později zaslaném e-mailu Jason upřesnil, že se jedná spíše o 10 MB. ...

Celé je to dobrý nápad, ale stejně bych byl rád, aby celý ten mechanizmus byl postaven tak, aby jej bylo možno při kompilaci kompletně vyřadit.

[filbar]

A proč při kompilaci? Nebylo by lepší při bootu udělat volbu pro debug a non nebug jádro?

[D.A.Tiger]

No jde mi o to, že jsou stroje, kde takový věci nechci a nevyžaduji; navíc, čím méně je tam zbytečností, které zabírají paměť, zdržují při startu, nebo při práci (jádra), tím lépe. A počítám, že pravděpodobně díky těm tabulkám to bude hodně rozlezlé po jádře, tak si říkám, že by bylo mnohem jednoduší to při kompilaci (vyžaduje-li to uživatel) to do toho jádra buď přidat, nebo to z něj vyříznout.

Konec konců, já mám na komplu většinou dvě verze jednoho jádra: optimalizovanou, co nejvíce monolitickou, ořezanou o všechny možné debug funkce a zbytečnosti na "ostrý provoz". Druhou zkompilovanou s různýma debug volbama a vším možným "co by se mohlo hodit na hraní" :) I když je pravda, že k té druhé se poslední dobou dostávám čím dál, tím méně.... Není holt "na hraní" čas...

[Otto Šabart]

Po více než třech letech se jasné

Po více než třech letech je jasné