Portál AbcLinuxu, 6. května 2025 18:19
Rychlost vývoje jádra. Verze linuxového jádra: Sága pokračuje. Zjišťování změny rychlosti CPU. Linux 2.6.9-mm1; Hans Reiser o ReiserFS4.
Do konference přišlo celkem 2759 emailů, nejvíce jich poslali Greg KH, Andrew Morton a Lee Revell.
19. říj - 22. říj
Jeffa Garzika zaskočilo a zároveň na něj udělalo dojem, že během 24 hodin od vydání Linuxu 2.6.9 bylo do stromu jádra přidáno celých 850 changesetů [sady změn] a 3383 revizí. Ben Dooks poznamenal, že on a další na tuhle verzi čekali, takže měli pro okamžik vydání patche připraveny. Dave Jones se vyjádřil, že by to mohlo být znamením pro kratší -rc období.
Jeff odpověděl: Spíše potřebujeme delší non-rc období.. Russell King na to reagoval: Osobně si myslím, že máte pravdu oba. Jedno velké vydání jádra za měsíc se zdálo být přibližně správným tempem. Možná by pomohl týden a půl navíc pro non-rc a dva a půl týdne navíc pro -rc.
Jens Axboe také odpovídal Jeffovi: Tempo změn je skutečně úctyhodné (díky, Andrew a BK!), ale byl bych radši, kdyby se věci zklidnily daleko rychleji. Místo 2-3 týdenní nepřetržité záplavy patchů bych byl pro týden začleňování věcí, které již byly v době 2.6.9 hotové podle Andrewových kritérií pro začlenění (se kterými plně souhlasím), což by vyústilo v -rc1. Následovaly by 2-3 týdny skutečně stabilizačního opravování chyb. Protože na základě těchto kritérií pro začlenění je vývoj dané funkce/změny hotov v době vydání 2.6.9, mělo by to být snadné (no dobře, aspoň to můžeme zkusit).
Pavel Machek navrhl vytvoření větve 2.7 a zkrácení období mezi 2.7 a 2.8.
Na jiném místě se Matt Heler zeptal, kolik změn proběhlo mezi 2.6.8 a 2.6.9, a Jeff odpověděl: 'bk pull' říká 4000 revizí ChangeSetů a 15723 revizí celkem (ta čísla obsahují slučovací changesety, což je nafukuje).
Bereme-li 'patch' jako unikátní záznam v changelogu, vypadá to, že do jádra 2.6.9 bylo přijato přes 3500 samostatných patchů. To je přes tisíc více než bylo přijato do jader 2.6.8 nebo 2.6.7. Kernel 2.6.6 se svými 1700 pobral ještě méně než kterýkoliv z těch dvou a 2.6.5 měl ještě méně. Vypadá to, že vývoj řady 2.6 začíná nabírat obrátky. Pro srovnání: do řady 2.4 přijal Marcelo Tosatti v průměru 220 patchů na kernel za stejný počet verzí.
19. říj - 27. říj
Benjamin Herrenschmidt měl požadavek ohledně označování verzí jádra. Viz Jaderné noviny 282: Vývojářům se nelíbí změny, které provádí Linus s názvy verzí, kde jsou další stížnosti. Tentokrá Benjamin napsal: Když v BK označíš strom jako "release" [k vydání], mohl bys rovnou zvýšit i číslo verze (a přidat něco do EXTRAVERSION - třeba "-devel")? Je docela otrava, když dochází ke konfliktu v názvech adresářů s moduly mezi "čistým", finálním stromem a nějakými vývojářskými věcmi, které testujeme z BK. Když přejdeš na -rc1, je to v pohodě, ale mezitím je to fakt protivné.
Jeff Garzik pro něco takového pochopení neměl a poukázal na to, že příkaz 'echo "-bk" > localversion' by problém vyřešil pro kterýkoliv snapshot z BitKeeperu. Ale několik dalších vývojářů se k Benjaminovi přidalo, včetně Lena Browna, který řekl: Také by mi to připadalo velmi šikovné. Během poslední doby, řekněme mezi 2.6.9 a 2.6.10-něco mi kompilační/instalační skripty přepisovaly mé "referenční" kernely.
Linus Torvalds odpověděl:
Osobně bych daleko radši šel stejnou cestou jako doposud, protože na verzích modulů mi záleží o dost méně než na verzích zpráv o chybách. A když slyším o chybě v 2.6.10-rc1, chci si být jistý, že jde skutečně _alespoň_ o 2.6.10-rc1 - jestli rozumíte, co mám na mysli.
Já sám bych radši věděl, přesně který z changesetů je na vrchu stromu. Takže jsem uvažoval o něčem, co by jej uložilo někam pryč. Ale pak bychom museli něco udělat pro uživatele, kteří nepoužívají BK (noční snapshoty by ho musely nakřečkovat někam bokem). To by vyřešilo jak verze modulů, tak problém s chybovými zprávami.
Takže jestli někdo přijde s kompilačním skriptem, který takovou extra-verzi vygeneruje automaticky, budu vstřícnější. Nechci však do verze ručně rýpat způsobem, o kterém si myslím, že není správný.
Måns Rullgård odpověděl: Fungovalo by, kdyby se někde v rámci Makefile kontrolovala existence BitKeeper adresáře? A pokud by existoval, bk by byl spuštěn s příslušnými parametry a něco by se přidalo do EXTRAVERSION. Nejsem si však tak docela jistý, jaké informace by bylo nejvhodnější přidat.
A Linus napsal:
Tak jsem to myslel. Ale mělo by to zároveň kontrolovat, jestli už je vršek stromu označen - a nic s tím nedělat. A také by měl pokud možno existovat CVS/Subversion protějšek, aby se lidi necítili vynechaní.
Navrhoval bych jen exportovat označení vršku stromu do nějakého souboru /sys/kernel/version (pro kompletní chybové zprávy), ale zároveň z něj udělat malou zkratku (jen pár nesmyslných znaků) v "uname", aby fungovaly verze modulů.
Takže "uname -r" by mohlo vypsat "2.6.9-a$Uv", ale
cat /sys/kernel/version/*
by vypsalo něco jako
soubor "kernel":
v2.6.9-a$Uv
soubor "bk-key":
torvalds@ppc970.osdl.org|ChangeSet|20041021004441|21737
soubor "date":
Wed Oct 20 22:29:23 PDT 2004
nebo tak něco (jedna hodnota na soubor, jako obvykle).
Jinde řekl Jeff, že Linusův požadavek vědět o changesetu z vršku stromu je zbytečný, protože:
Noční snapshoty to exportují od prvního dne, na základě tvého
požadavku 
.
<snapshot>.key tyto informace obsahuje, např.: http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.9-bk1.key je vršek stromu pro http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.9-bk1.bz2
Linus odpověděl:
Ano. Ale to nepomůže lidem, kteří ty původní BK stromy skutečně pro sebe používají, nebo těm, kteří využívají CVS exporty. To je to, na co si stěžoval Ben.
Už máme koncept souborů "localversion*", které jsou ke kompilaci připojeny. Takže jedinou věcí, která by byla potřeba, je trochu magie v Makefile, která by vytvořila soubor "localversion-bk-verze", kdyby nebyl vršek stromu označen. A tím bychom získali i unikátní ID pro uživatele původních BK.
Ryan Anderson původní Linusův návrh skutečně implementoval a následovala technická diskuze, která však zůstala bez výsledku.
21. říj - 25. říj
Lee Revell se zeptal, jak by mohla aplikace zjistit, že se změnila rychlost CPU v běžícím systému. Zeptat se souboru v /sys nestačí. Kolem toho by bylo moc práce a my musíme vědět teď. Je tohle ten druh věci, která by vyžadovala nové to rozhraní pro události jádra [kernel event interface]?
Alan Cox a další napsali, že to není nic jenoduchého. Matthew Garrett k tomu poznamenal: Kernel vždy neví, že se změnila rychlost CPU. A to upozorňování poněkud ztěžuje. Robert Love odpověděl na to, jestli by rozhraní událostí jádra bylo pro tuto věc dobrým nástrojem: Ano, myslím, že vytvoření kevent svázané s procesorem při změně rychlosti je ideálním využitím vrstvy událostí jádra.
Lee byl překvapen Matthewovým (a Alanovým) tvrzením, že kernel ne vždy ví o rychlosti CPU: Copak by to nezpůsobovalo podivné chování? Například Linux vypočítává delay smyčku pouze při startu. Znamená to tedy, že *delay() je k ničemu? Alan odpověděl: Takové systémy je potřeba spouštět s notsc - i když 2.6 to detekuje automaticky, stěžuje si a zařídí to sám.
Diskuze se brzy vytratila bez jasného řešení problému, se kterým Lee přišel.
22. říj - 27. říj
Andrew Morton oznámil Linux 2.6.9-mm1 a mezi věcmi, které čekají na začlenění, zmínil i:
Hans Reiser k Reiser4 řekl:
Žádná distribuce, která používá jako výchozí souborový systém ReiserFS v3, v tom nebude pokračovat, jakmile Reiser4 dosáhne jejích požadavků na stabilitu. Mnoho lidí ReiserFS používá a Reiser4 z něj dělá zastaralou věc - a uživatelé to vědí. Žádná z distribucí nevyjádřila záměr pokračovat s v3 - a byli by hloupí, kdyby ano. Vypadá to, že příští rok přesáhne počet distribucí používajících Reiser4 jako výchozí počet těch, které teď mají v3. Vyšší výkonnost v4 zvýší náš podíl na trhu.
Doporučuji začlenit v4 coby experimentální filesystém PŘEDTÍM než jej prodejci začnou nabízet. Myslím, že dává smysl dát experimentální věci nejprve do kernelů používaných hackery. Vytváří to větší komunitu.
Chtěl bych poukázat na to, že v jádře je mnoho věcí, které jsou o hodně méně stabilní než Reiser4.
Zařazení do -mm odhalilo nějaké chyby a jednu ze zásadnějších oprav stále testujeme. Před tím než požádám o začlenění, bych to testování rád dokončil (ne více než 7 dní) a pak pošlu všechny opravy.
Hellwig také správně poukázal na to, že by bylo dobré se zbavit některých maker, která ztěžují čitelnost (já také nesnáším kód, který editorům znemožňuje nalézt volané funkce), a zam na tom pracuje.
Lindows plánuje dodávat příští verzi s Reiser4 a já bych se moc rád dočkal začlenění ještě před tím.
V originálu Kernel Traffic 283 vyšla navíc ještě tato témata:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.