![[cesty začleňování do 2.6.35]](/images/clanky/bourek/trees-2.6.35.png)
Portál AbcLinuxu, 4. května 2025 19:24
Aktuální verze jádra: 2.6.35-rc4. Citáty týdne: Dave Airlie, Rusty Russell. Ptejte se jaderného vývojáře. O škálovatelnosti Linuse. Příliš mnoho přetažení?
Současné vývojové jádro je 2.6.35-rc4 vydané 4. července. Už týden jsem zase online a soudě podle patchů a požadavků na přetažení, které dostávám, musím říct, že když jsem byl u -rc3 striktní, fungovalo to poměrně dobře. Diffstat mezi rc3 a rc4 vypadá docela rozumně i přes delší okno mezi -rc. A i když se rozhodně objevily věci, které potřebovaly opravit, doufám, že i přes mou dovolenou vyjde 2.6.35 včas […] Co se detailů týče, k dispozici jsou zkrácený changelog i kompletní changelog.
Stavidla stabilních jader se otevřela a vyplaveno bylo pět různých stabilních jader: 2.6.27.48, 2.6.31.14, 2.6.32.16, 2.6.33.6 a 2.6.34.1. Žádná další jádra 2.6.31 nebudou a pro vydání 2.6.33 vyjde už jenom jedna aktualizace. Ostatní budou ještě nějaký čas aktualizována.
-- Dave Airlie
Originál tohoto článku pro lwn.net napsal Greg Kroah-Hartman.
Jeden sloupek ze série, ve které se ptáte vývojáře jádra a on se snaží vaše dotazy zodpovědět. Pokud máte nějaké nezodpovězené dotazy ohledně technických nebo procedurálních záležitostí linuxového jádra, můžete je položit v sekci pro komentáře u originálu článku, nebo je zaslat e-mailem přímo autorovi.
Jak zjistím, komu napsat o problému, který mám s jádrem. V jaderném logu vidím různé zprávy, jak podle nich poznám, který vývojář mi může pomoci?
Například teď vidím následující chybu:
[ 658.831697] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 658.831702] 48 48 48 48 50 50 50 50 20 20 20 20 4c 4c 4c 4c HHHHPPPP LLLL
[ 658.831705] 50 50 50 50 33 33 33 33 30 30 30 30 36 36 36 36 PPPP333300006666
[ 658.831709] 35 35 35 35 0a 0a 0a 0a 20 20 20 20 20 20 20 20 5555…
Kde mám začít, abych problém dohledal?
Jaderný log ti říká, kde je problém, takže trik spočívá v tom zjistit, kdo je za zprávy zodpovědný. Jsou různé způsoby, jak na to. Nejprve můžeš zkusit grepovat zdrojové kódy jádra a hledat chybovou zprávu:
$ cd linux-2.6 $ git grep "\*ERROR\* Raw EDID"
Ok, to nic neudělalo, takže zkusíme řetězec trochu zkrátit:
$ git grep "Raw EDID"
drivers/gpu/drm/drm_edid.c: DRM_ERROR("Raw EDID:\n");
Ok, teď máš soubor, do kterého se můžeš podívat. Ale kdo je za něj odpovědný? Jak bylo zmíněno dříve, můžeš použít skript get_maintainer.pl, kterému předáš jméno souboru, který tě zajímá:
$ ./scripts/get_maintainer.pl -f drivers/gpu/drm/drm_edid.c David Airlie <airlied@linux.ie> Dave Airlie <airlied@redhat.com> Adam Jackson <ajax@redhat.com> Zhao Yakui <yakui.zhao@intel.com> dri-devel@lists.freedesktop.org linux-kernel@vger.kernel.org
To nám ukázalo, že nejlepší osoba, které se zeptat, je hlavní vývojář DRM David Airlie, ale pomoci by mohli i další vývojáři. Když pošleš e-mail Davidovi a do CC přidáš ostatní zmíněné (včetně e-mailových konferencí), dostane se těm, kteří by nejpravděpodobněji mohli pomoci.
Další možnost, jak zjistit, který kód je za problém zodpovědný, je podívat se na jméno funkce, která chybu vypisuje:
[ 658.831697] [drm:edid_is_valid] *ERROR* Raw EDID:
Jméno funkce je uzavřeno v závorkách [] a můžeme se podívat, který kód ji volá:
$ git grep edid_is_valid
drivers/gpu/drm/drm_edid.c: * drm_edid_is_valid – sanity check EDID data
drivers/gpu/drm/drm_edid.c:bool drm_edid_is_valid(struct edid *edid)
drivers/gpu/drm/drm_edid.c:EXPORT_SYMBOL(drm_edid_is_valid);
drivers/gpu/drm/drm_edid.c: if (!drm_edid_is_valid(edid)) {
drivers/gpu/drm/radeon/radeon_combios.c: if (!drm_edid_is_valid(edid)) {
include/drm/drm_crtc.h:extern bool drm_edid_is_valid(struct edid *edid);
To opět ukazuje, že za chybovou zprávu je odpovědný soubor drivers/gpu/drm/drm_edid.c.
Když se podíváme na funkci drm_edid_is_valid, před touto zprávou jádro mohlo vypsat i další:
if (csum) {
DRM_ERROR("EDID checksum is invalid, remainder is %d\n", csum);
goto bad;
}
if (edid->version != 1) {
DRM_ERROR("EDID has major version %d, instead of 1\n", edid->version);
goto bad;
}
Když tedy posíláš e-mail vývojářům a do e-mailových konferencí, které jsi našel skriptem get_maintainer.pl, je vždy důležité poskytnout všechny jaderné logy, ne jenom několik posledních řádek chyby, protože o něco výše může být víc informací, které mohou vývojáři použít pro odladění problému.
[Za zaslání této otázky díky Peteru Favrholdtovi.]
napsal Jonathan Corbet, 2. července 2010
Vývojový proces Linuxu v mnoha ohledech vyniká; jedním z nich je fakt, že do „oficiálního“ repozitáře kód vkládá právě jedna osoba. O různé subsystémy se stará mnoho různých správců, ale každý patch, který tito správci začlení, musí nakonec přijmout Linus Torvalds, pokud se má dostat do hlavní řady. Linusova unikátní role tento proces mnoha způsoby ovlivňuje; například nyní, když je tento článek sepisován, se Linus právě vrátil z dovolené, která vedla k tomu, že do hlavní řady nebylo pár týdnů začleňováno nic. S tímto modelem jediného vkladatele kódu jsou však spjaty mnohem vážnější záležitosti, přičemž škálovatelnost se pohybuje na čelních pozicích.
Někteří čtenáři Jaderných novin si určitě vzpomenou na vydání 2.1.123 v září 1998. Toto jádro se nedalo zkompilovat, protože Linus začlenil jenom část patchů pro framebuffer. Selhání překladu vývojového jádra nevypadá jako žádná velká krize, ale tato chyba se stala bodem, ve kterém se vybil vztek hromadící se v komunitě vývojářů: Patche byly čím dál tím více zahazovány a lidi to unavovalo. Na konci dlouhé a nepříjemné diskuze Linus rozhodil rukama a šel pryč:
Samozřejmě se jedná o slavnou epizodu „Linusova vyhoření“ z roku 1998 (pozn. redakce: vizte článek Hořet, ale nevyhořet). Na chvíli se všechno zastavilo, dokud si Linus trochu neodpočinul, nevrátil se a nezačal opět začleňovat patche. Věci se opět trochu přiostřily roku 2000, což vedlo k trochu svatouškovské přednášce o prokletí nadaných od Erica Raymonda. Roku 2002, když se pracovalo na řadě 2.5, frustrace ze zahozených patchů opět vzrostla; základem pro další dlouhý flamewar o nefunkční podobě vývojového procesu jádra a o problému „Linus neškáluje“ byl tenkrát návrh „patchujícího tučňáka“ Roba Landleyho.
Krátce poté se věci mnohem zlepšily. Není pochyb o tom, co je změnilo: Přijetí BitKeeperu – přes všechny flamewary, které kvůli tomu vznikly – zajistilo, že vývojový proces jádra začal fungovat. Přechod ke Gitu věci vylepšil ještě více; ukazuje se, že se správnými nástroji Linus škáluje velmi dobře. V roce 2010 zvládá takový objem patchů, který by tenkrát byl nemyslitelný, a vývojový proces přitom funguje velice hladce.
Autor článku má nicméně obavu, že se na horizontu objevují mraky; blíží se další bod, kde se narazí na Linusovu škálovatelnost? V cyklu 2.6.34 Linus zavedl politiku nepředvídatelné délky začleňovacího okna – i když se zatím jednalo spíše o řeči než o činy. V případě 2.6.35 poměrně dost vývojářů zůstalo, co se požadavků na přetažení [pull request] týče, bez odezvy; Linus se je prostě rozhodl ignorovat. Výbuch ohledně architektury ARM toho byl součástí, ale nebyly přetaženy i další stromy. Do těch špatných dní, kdy patche jednoduše mizely v prázdnotě, jsme se nevrátili a Linus možná jenom trochu experimentuje s vývojovým procesem, aby některé správce vybídl k jinému chování. I tak ale tiché ignorování požadavků na přetažení vyvolává špatné vzpomínky z té doby.
V typickém vývojovém cyklu je do hlavní řady začleněno více než 10 000 změn. Linus se však většiny těchto patchů nedotýká: Místo toho je přetahuje ze stromů, které spravují správci subsystémů. Kolik pozornosti je věnováno specifickým požadavkům na přetažení, není zcela jasné; na každý se Linus dívá dostatečně zblízka, aby se ujistil, že je v něm to, co mu řekl správce. Některá přetažení jsou zjevně podrobena bližšímu zkoumání, zatímco jiná projdou jenom s krátkou prohlídkou. I tak je jasné, že každý požadavek na přetažení a každý patch vyžaduje nějakou pozornost a přemýšlení, než je začleněn.
Následující tabulka shrnuje Linusovu začleňovací aktivitu pro posledních deset verzí jádra (řádka 2.6.35 odráží stav do 2.6.35-rc3):
| Verze | Přetažení | Patche | ||
|---|---|---|---|---|
| Začleňovací okno | Celkem | Přímo | Celkem | |
| 2.6.26 | 159 | 426 | 288 | 1496 |
| 2.6.27 | 153 | 436 | 339 | 1413 |
| 2.6.28 | 150 | 398 | 313 | 954 |
| 2.6.29 | 129 | 418 | 267 | 896 |
| 2.6.30 | 145 | 411 | 249 | 618 |
| 2.6.31 | 187 | 479 | 300 | 788 |
| 2.6.32 | 185 | 451 | 112 | 789 |
| 2.6.33 | 176 | 444 | 104 | 605 |
| 2.6.34 | 118 | 393 | 94 | 581 |
| 2.6.35 | 160 | 218 | 38 | 405 |
Dva sloupce pod „přetažení“ ukazují počet stromů, ze kterých se přetahovalo během začleňovacího okna a během vývojového cyklu jako celku. Je potřeba říci, že tato čísla mohou být příliš malá, protože začleňování „rychle vpřed“ [fast-forward] v historii gitu nemusí ponechávat žádné stopy. Linus ale dělá jenom málo začlenění „rychle vpřed“, takže počet přehlédnutých začlenění bude malý, pokud vůbec nějaká budou.
Linus také některé patche začleňuje přímo. Většina z nich pochází od Andrewa Mortona, který k předávání patchů Linusovi nepoužívá git. V tabulce výše sloupec „celkem“ zahrnuje změny, které přišly od Andrewa, zatímco sloupec „přímo“ počítá pouze patche, se kterými nepracoval Andrew.
Z této tabulky jsou zjevné trendy: Počet patchů, které jdou přímo do hlavní řady, významně poklesl; téměř všechno nejprve prochází přes něčí strom. Na Linuse v tomto okamžiku zbývá povětšinou jenom označování verzí, urgentní opravy a reverty. Andrew Morton zůstává pro velkou část jádra správcem poslední záchrany, ale čím dál tím více změny neprochází ani přes jeho strom. Počet přetažení přitom zůstává přibližně stejný. Bylo by zajímavé zamyslet se nad tím, proč to tak je.
I přes rostoucí počet stromů možná není potřeba víc přetažení. A nebo se blížíme přirozenému limitu toho, kolika požadavkům na přetažení ze subsystému dokáže jeden talentovaný benevolentní diktátor věnovat pozornost, aniž by vyhořel. Konec konců dává rozum, že počet požadavků, které Linus zpracuje, se nemůže neomezeně zvyšovat; jestliže jaderná komunita dál poroste, musí se zde zákonitě objevit úzké hrdlo škálovatelnosti. Zůstává jediná otázka, kdy by to mohlo nastat.
Pokud zde máme oprávněné obavy, mohlo by stát za to zamyslet se nad reakcí dříve, než se věci zase rozbijí. Jedním ze zjevných přístupů by mohlo být změnit fakt, že jsou téměř všechny stromy přetahovány přímo do hlavní řady; na obrázku vpravo můžete vidět, jak plochá je tato struktura u 2.6.35. Správci subsystémů, kteří si vysloužili dostatečnou důvěru, by mohli řešit více požadavků na přetažení z nižší úrovně a výsledek předložit Linusovi s tím, že ho může začlenit s relativně malými starostmi. Subsystém síťování takto již funguje; mnoho stromů plní strom síťování Davida Millera předtím, než jsou patche zaslány výše. Na druhou stranu různé tlaky vedly k tomu, že na straně architektury ARM dochází k opačnému procesu: Nyní je zde několik stromů subarchitektur, které jdou přímo Linusovi. Počet přetažení u ARM se zjevně stal Linusovou motivací pro ukončení začleňovacího okna 2.6.35.
Další řešení by bylo dát dalším lidem moc vkládat stromy přímo do hlavní řady. Není ale jisté, jestli je někdo připraven na takto radikální změnu ve vývojovém procesu jádra. A varování Teda Ts'o z roku 1998 všem, kteří by si přáli model „vnitřního týmu“, stojí za přečtení i po dvanácti letech.
Jestliže si ale Linus ponechá svou pozici ve vývoji Linuxu pouze pro sebe, komunita jako celek bude muset zajistit, že proces jako takový bude škálovat a nezaplaví ho. Zajistit, aby více začlenění probíhalo před tím, než se kód dostane k Linusovi, vypadá jako přístup se slibným potenciálem, ale autor článku se doslechl, že Linus není moc nakloněn přílišnému slučování stromů; chce si věci na cestě do hlavní řady prohlédnout. I tak ale musí být místa, kde by to fungovalo. Možná potřebujeme strom, který by zase zastřešil celou architekturu ARM, a možná by mohlo být místo pro strom, kde by se shromažďovaly patche pro většinu ovladačů.
Linuxové jádro a jeho vývojový proces je mnohem větší než roku 2002. Pokud by se tento proces měl znovu zadrhnout kvůli problémům se škálovatelnosti na vrcholu, důsledky by byly mnohem viditelnější veřejnosti. I když tu není nebezpečí akutních potíží, neměli bychom se plynulostí, s jakou se pracovalo posledních několik let, nechat ukolébat k tomu, že se nic podobného nemůže stát. Stejně jako u kódu samotného je dobré myslet na problémy se škálovatelností dříve, než udeří.
.
23.7.2010 02:55
poky74 | skóre: 36
| blog: Zápisník
| Vrchlabí
To si nedovedu dost dobře představit. Že by každý dělal půlku práce? To je nesmysl. Vanilkové jádro je jen jedno, proto je pro něj nejlepší když se o něj stará právě jeden člověk.
).
kterej proste rekne "Udelame to takhle!"Ovšem jen pokud pak neříká: "nestíhám!". Složitost jádra roste imho dost silně je klidně možný, že brzy překročí stav, kdy ho jeden člověk už nezvládne sledovat.
a kolik je pro nej jen rutinni zalezitostNo a právě tady by to za něj mohl dělat někdo jinej a ušetřit drahé Linuso-hodiny
.
23.7.2010 11:24
Jendа | skóre: 78
| blog: Jenda
| JO70FB
První verze linuxového jádra (0.01) byla na Internetu zveřejněna 17. září 1991.odsud. P.S. Já to vždycky zaregistruju až ze zpráviček tady
.
25.8.1991 - neznámý finský student Linus Benedict Torvalds zaslal do diskuzní skupiny comp.os.minix příspěvek s předmětem "What would you like to see most in minix?". O tom, že vyrábí free operační systém - nic komerčního a velkého, pouze jen tak ze zábavy.Rozdíl je v tom, že pro vás je podstatný porod, kdežto pro mne početí..
).
pro vás jeP.S. Pokud to není do publika, tak >patička<.
23.7.2010 08:25
tsLnox | skóre: 31
| blog: Blog jednoho ukecaného Gentoolemana
| Žďár nad Sázavou
cože
24.7.2010 04:15
Jendа | skóre: 78
| blog: Jenda
| JO70FB
.
24.7.2010 17:07
poky74 | skóre: 36
| blog: Zápisník
| Vrchlabí
Má jen tuším 2 holky, šance že by šli ve šlépějích otce je mizivá, ale zajímavé by to bylo :)
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.