Portál AbcLinuxu, 5. května 2025 15:15
2.6.25-rc6, "začíná vypadat lépe". Stránky ve virtuální oblasti. 2.6.25-rc7, "většina změn je poměrně malá". Plány pro strom Linux-next. Souborový systém UBI. Porovnání UBIFS a LogFS. 2.6.25-rc8, "žádné roztomilé aprílové nesmysly". kmemcheck míří do hlavní řady jádra.
Následující obsah je © KernelTrap.
17. březen, originál
Přišel jsem tento týden o den a půl kvůli disku, který se rozhodl hlásit chyby při čtení po nešťastném výpadku napájení, a já musel strávit příliš mnoho času obnovou svého obvyklého nastavení, začal Linus Torvalds oznámení jádra 2.6.25-rc6, nicméně si nemyslím, že bych ztratil nějaké e-maily, a zdálo se, že věci se poněkud zklidnily, takže doufám, že -rc6 začíná vypadat lépe. Poté shrnul změny:
Dirstat ukazuje obvyklý vzor, většina změn je mezi ovladači a aktualizacemi architektur, nicméně tentokrát je to poněkud posunuté aktualizacemi v parisc a powerpc (čímž mezi jinými snad uzavíráme regresi při překladu u parisc), což znamená, že architektury zabírají polovinu a ovladače těsně pod třetinu patche (obvykle je to obráceně.)
Došlo k velkému selhání systému a údržbáři hardwaru a softwaru potřebovali několik hodin na to, aby to opravili. Potom jsme pomalu obnovili jeden e-mailový subsystém po druhém, abychom ověřili správné fungování. Teď si zase užíváme záplavu mailů ;-).
Matti Aarnio, zpráva z 19. března 2008 na Linux Kernel mailing list.
21. březen, originál
Alokace větších stránek není v Linuxu spolehlivá. Jestliže je potřeba je alokovat, pak má člověk na výběr mezi vytvořením nějakého způsobu čistého zotavení a použitím vmalloc, který má kvůli používání tabulky stránek dopad na výkon, oznámil Christoph Lameter třetí verzi sady patchů stránek ve virtuální oblasti (virtual compound pages). Alokace virtuální oblasti znamená, že nejprve proběhne pokus vyřídit požadavek alokací fyzicky souvislé paměti. Pokud to není možné, vytvoří se virtuálně souvislá paměť. Christopher ukázal dvě výhody:
1. Současná využití vmalloc mohou být konvertována tak, aby alokovala virtuální oblasti. Ve většině případů je možné použít fyzicky souvislou paměť, takže nedojde k poklesu výkonu.
2. Používání alokací vyšších řádů (zásobníky, buffery atd.) může být nahrazeno virtuálními oblastmi. Obecně se pro tyto oblasti bude používat fyzicky souvislá paměť, ale systém se může snížit k využití vmalloc, pokud dojde ke značné fragmentaci paměti.
AppArmor může jít k čertu. Nejvhodnější oprava je přenést ty LSM nesmysly k volajícímu a nechat vfs_...() na pokoji.
Al Viro, zpráva z 21. března 2008 na Linux Kernel mailing list.
26. březen, originál
Tahle verze doufejme uzavírá různé regrese a většina změn je poměrně malá (tj. diffstat zobrazuje mnoho jednořádkových úprav). Největší patche jsou jednoduché aktualizace defconfigu u powerpc, které jsou v dirstatu velmi výrazné, tj. kdyby tam nebyly, aktualizace v /arch by se téměř nechaly přehlédnout. Linus Torvalds oznámil jádro 2.6.25-rc7. Poznamenal, že byl odstraněn ovladač ps2esdi, který byl několik let označen jako nefunkční, a přidán ovladač metronomefb.c pro E-Ink Metronom.
Kromě těchto je většina změn poměrně malá a rozprostřená. Plánovači se dostalo nějakého ladění, ovladači memstick nějaké péče a cifs a reiserfs nějakých oprav. Zkrácený log obsahuje víc detailů, ale jinak se scvrkl na reverty, opravy docbooks, pár různých oprav anotací, větší množství triviálních patchů a zdravou spršku malých oprav.
Ve shrnutí Linus navrhl: Dobře ho otestujte, protože jsme snad na dobré cestě k vydání skutečného 2.6.25!
Od toho bodu dál musíš jít se všemi problémy za nVidií, protože oni mají všechny zdrojové kódy, kdežto my jejich ne.
Alan Cox, zpráva z 26. března 2008 na Linux Kernel mailing list.
27. březen, originál
Teď, když se (předpokládejme) blížíme k dalšímu začleňovacímu oknu, můžu se zeptat, jak (jestli) budete používat strom linux-next? Nebo jinak: je nějaká informace, kterou od něj požadujete? ptal se Stephen Rothwell ohledně stromu sledujícího nadcházející začlenění do stable, s jehož správou začal minulý měsíc.
Andrew Morton odpověděl: Strom už funguje. Úroveň chyb začlenění a chyb při překladu v subsystémových stromech je v této době jenom zlomek toho, co bylo ve stejné fázi jádra 2.6.24-rcX. Pokračoval poznámkou, že v současnosti je v -mm stromu hostováno 60 až 80 subsystémových stromů.
Potřebuji najít způsob, jak a) dostat do linux-next vyspělé části těchto stromů a b) založit zbytek -mm na linux-next. O tom jsem ještě nezačal přemýšlet. Zdá se, že některé stromy, z nichž některé jsou významné, ještě v linux-next nejsou.
Je těžké přimět lidi z POWER, aby akceptovali, že během posledních třiceti let byli, co se týče VM, totální tupci, to si uvědomuji. Nicméně někomu z tábora vývojářů POWER hardwaru (a) by se to říct mělo a (b) dotyční by se měli stydět.
Linus Torvalds, zpráva z 26. března 2008 na Linux Kernel mailing list.
28. březen, originál
Tady je nový souborový systém pro flash paměti vyvinutý techniky v Nokii s pomocí University of Szeged. Nazývá se UBIFS, což je zkratka pro UBI file system. UBI je vrstva, která vyrovnává opotřebení (wear-leveling), řeší vadné sektory a spravuje svazky a již je v hlavní řadě jádra (vizte drivers/mtd/ubi), psal Artem Bityutskiy. Vysvětlil, že UBIFS je stabilní a velmi blízko ke stavu, kdy bude připraven k vydání. V porovnání s JFFS2 se zaměřuje na zvýšení výkonu a škálovatelnosti tím, že implementuje cache se zpětným zápisem [writeback caching] a ukládá index souborového systému místo toho, aby ho obnovoval pokaždé, když je médium připojeno. Oproti JFFS2 implementace cache se zpětným zápisem slibuje okolo stonásobného zlepšení výkonu při zápisu. Artem pokračoval poznámkou:
UBIFS pracuje nad UBI, ne přímo nad flash zařízením. Na UBI deleguje kritické věci, jako je sběr odpadu (garbage-collection) a řešení špatných erasebloků. Jedna důležitá poznámka je, že MLC NAND flash paměti mívají malou životnost erasebloků - pouze několik tisíc přepisových cyklů (některé mají dokonce i 3000 nebo méně). Kvůli tomu není algoritmus pro vyrovnávání opotřebení v JFFS2, který je založený na náhodném přístupu, dost dobrý. Naproti tomu UBI poskytuje vyrovnávání opotřebení založené na uložených čítačích výmazů.
Ty se hádáš o tom, že konzistentní styl kódu je špatný? Tahle diskuze byla ukončena dávno, když bylo napsáno Documentation/CodingStyle. Od veškerého jaderného kódu se očekává, že tento styl bude dodržovat - kromě případů, kdy by výsledná řádka kódu vypadala zjevně špatně. Zdá se, že tvoje argumentace se soustředí na "hej, můj způsob vypadá podobně dobře, takže to budu dělat takhle, protože jsem správce" - tenhle argument nemá žádnou váhu. CodingStyle není slovo boží a měl by být uplatňován selský rozum, ale libovolně a záměrně ho nedodržovat se považuje za špatné vychování, které škodí Linuxu jako celku.
Ingo Molnár, zpráva z 26. března 2008 na Linux Kernel mailing list.
31. březen, originál
Po nedávném oznámení, že UBIFS je téměř připraven k vydání se objevila žádost o porovnání UBIFS a LogFS. Autor LogFS Jörn Engel odpověděl: Oba mají podobné cíle. Největší rozdíl je, že ubifs pracuje nad ubi a závisí na něm, zatímco logfs pracuje přímo nad mtd (nebo blokovým zařízením) a všechno dělá sám. Rozdíl ve velikosti kódu je obrovský. Ubi má 11kloc, ubifs nějakých 30, logfs nějakých 8.
Ubi škáluje lineárně a během inicializace provádí rozsáhlý scan. I tak je rozumně rychlý, protože čte z každého bloku jenom pár užitečných bajtů z hlavičky. Logfs připojuje se složitostí O(1), ale v současnosti je depresivně pomalý, když se souborový systém blíží ke stoprocentnímu zaplnění a zápisy jsou čistě náhodné. Ne že by se jiné filesystémy pro flash paměti za těchto podmínek chovaly lépe - je to známý nejhorší případ.
Artem Bityutskiy odpověděl: Osobně odmítám srovnávat dokončený FS, který zvládá všechny schopnosti důležité pro flash, s nedokončeným FS. To prostě nedává smysl. O LogFS se mluvilo už v roce 2005 na Linux Kongresu, ale stále není dokončen. Mluvme o něm, až bude připraven k vydání.
Asi tak skvělé jako prd ve skafandru.
David Miller, zpráva z 31. března 2008 na Linux Kernel mailing list.
2. duben, originál
Žádné roztomilé aprílové nesmysly, prostě jenom obyčejné -rc vydání, které se náhodou objevuje dneska, protože jsem čekal, až budou hotové a otestované opravy oopsů ve vstupní vrstvě [input layer], začal Linus Torvalds oznámení o vydání jádra 2.6.25-rc8 1. dubna. Největší část oprav jsou obvyklé náhodné jednořádky [...] Spousta těch jednořádků jsou různě rozptýlená pročištění, která jsou v tuto chvíli nadbytečným šumem, ale když mi Al pošle sérii, většinou ji aplikuji, protože jeho patche bývají opatrné a v základu vždy správné.
Velká věc, která je skutečně pro většinu lidí zpozorovatelná, je ta, že tato verze by měla opravit dvě velké regrese: měli jsme jich pár v suspend-resume kvůli stupidním problémům v pořadí ACPI_PTS (Prepare to Sleep) a zatímco pročištění jsme nechali, změny v uspořádání byly vzaty zpět. Takže to by některým lidem mělo vyřešit problémy (samozřejmě, lidé, kterým ta změna problémy vyřešila, šťastní nebudou, ale ty regrese jsou horší). Druhá věc, která žrala hodně lidí a je nyní opravena (a která se pravděpodobně často projevovala jako regrese v suspend/resume), byly změny v životnosti struct device, které rozbily vstupní vrstvu. Děkuji lidem, kteří tohle ladili.
Soutěžení je dobrá věc. Není nad tu smršť patchů, která se strhne po benchmarku, který je pro jednu či druhou stranu nepříznivý.
Jörn Engel, zpráva z 31. března 2008 na Linux Kernel mailing list.
4. duben, originál
Vynechal jsem veřejné oznámení verzí 5 a 6, ale 7 je tady :), psal Vegard Nossum v oznámení nejnovější verze jeho patche kmemcheck, který se v současnosti aplikuje na jádro 2.6.25-rc8. Vegard poznamenal, že doufá, že patch bude začleněn do hlavní řady jádra během začleňovacího okna 2.6.26. Patch popsal:
Kmemcheck je patch, který detekuje používání neinicializované paměti. To dělá odchycením všech čtení a zápisů do paměti, která byla alokována dynamicky (např. použitím kmalloc()). Jestliže se čte z paměťové adresy, na kterou se předtím nezapisovalo, do jaderného logu se vypíše hlášení.
V porovnání s předchozími verzemi prošla v7 značným pročištěním, byly zahájeny některé přípravy pro port na x86_64, byla vylepšena stabilita hlášení chyb, přidány volby jak pro čas bootování, tak pro čas běhu a opraveno několik chyb.
Velká věc (v mnoha směrech) v tomto vydání je přidání podpory pro s390. Protože není zahrnutá v tarballu, budete potřebovat git, abyste ji stáhli. Taky budete potřebovat mainframe.
Avi Kivity, zpráva z 6. dubna 2008 na Linux Kernel mailing list.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.