Jaderné noviny 316

29. 7. 2005 | Robert Krátký

Články - Jaderné noviny 316  

Migrace na 4K kernel stacks. Shrnutí real-time problémů. DevFS odstraněno z Linuxu. Linux 2.4 nebude podporovat GCC 4. Linuxová dokumentace, kterou lze prohlížet jen v nelinuxových prohlížečích.

Poznámka překladatele: Tento díl Jaderných novin vychází s tak velkým zpožděním, protože jsem originál KT 316 - jakkoliv se mi samotnému nechtělo uvěřit - přehlédl. Prostě vyšel, ale já si toho nevšiml...

Migrace na 4K kernel stacks, 13 e-mailů

07. črv - 10. črv

Adrian Bunk napsal:

4Kb kernel stacks jsou budoucností pro systémy i386 a vypadá to, že problémy, které ze začátku způsobovaly, jsou již vyřešeny.

Rád bych:

• dostal do dalšího -mm patch, který by bezpodmínečně zapínal 4KSTACKS
• nevyskytnou-li se chyby, tak bych do 2.6.13 nebo 2.6.14 poslal patch, který by zcela odstranil !4KSTACKS.

Jediným problémem je, že na !4KSTACKS stále závisí REISER4_FS. Už v březnu jsem Hansovi říkal, že je potřeba to změnit.

Máte představu, za jak dlouho by mohly být všechny 4K problémy v Reiser4 vyřešeny?

Pokud ne, budou se možná lidi, kteří používají Reiser4, rozhodnout, jestli změnit souborový systém nebo architekturu...

Alexander Nyberg poukázal na to, že určité kombinace konfiguračních voleb nebudou bez 4KSTACKS fungovat, takže to nemůžeš jen tak odstranit bez možnosti vybrat si. Před nějakou dobou to ani nebylo složité simulovat a nevšiml jsem si žádných patchů, které by redukovaly stacks v těchto oblastech. Trochu se diskutovalo o tom, jestli je to pořád problém, ale v konferenci se k žádnému rozhodnutí nedošlo.

Na jiném místě řekl Vladimir Saveliev, že se usilovně snaží vyřešit poslední zbývající problémy, které by měl ReiserFS bez 4KSTACKS, a odhadoval, že by patche mohl mít hotové velmi rychle.

Shrnutí real-time problémů, 103 e-mailů

07. črv - 14. črv

Paul E. McKenney napsal: Někdy během nedávného vlákna "RT patch acceptance" [přijetí RT patchů] někdo zmínil, že by bylo fajn shrnout všechny ty různé přístupy. Následující text se o to pokouší a zároveň se snaží poskytnout rozumný rámec pro budoucí diskuzi. Přiložil velmi dlouhý dokument, který byl chválen ze všech stran, protože dokázal zachovat vyrovnaný a nezaujatý pohled.

Mnoho lidí přišlo s návrhy, jak dokument vylepšit, ale konverzace degenerovala na další flamewar a obviňování. Původní zpráva však stojí za přečtení každému, kdo by se v tom bludišti rád vyznal.

DevFS odstraněno z Linuxu, 42 e-mailů

10. črv - 16. črv

Greg KH napsal:

Jak každý ví [1], devfs bude z jádra brzy odstraněno. Posílám sérii patchů (dohromady 22), které to zařídí. Překvapivě bylo devfs v jádře skoro všude, proto je potřeba tolik patchů :).

Pokud se některé do LKML neprobijí (kvůli omezením velikosti nebo prostě neprojdou filtrem "vkusu"), najdete je na:
../gregkh-2.6/gregkh-05-devfs/
včetně zastřešujícího souboru, pomocí kterého je můžete aplikovat.

Andrew, nedávej je prosím do svého -mm stromu. Je dost pravděpodobné, že akorát způsobí tolik konfliktů, že ti to nebude za tu námahu stát :).

Komentáře uvítám.

Jo, a ta nejlepší část? Tohle je shrnutí diffstat:

222 souborů změněno, 112 vložení(+), 8545 výmazů(-)

Je hezké taky jednou pro změnu kód z jádra odstraňovat...

Díky,

greg k-h

[1] Co? Vy to nevíte? Nedostali jste snad připomínku[2]? Nevšimli jste si toho obrovského flamewaru skoro před rokem[3]? Žijete v jeskyni[4]?
[2] feature-removal-schedule.txt
[3] http://thread.gmane.org/gmane.linux.kernel/219278
[4] ../shop/images/products/product_1788_small.jpg

Adrian Bunk řekl: Neodstraňuj prosím ty atrapy !CONFIG_DEVFS_FS z devfs_fs_kernel.h. Jsem si jistý, že někteří správci ovladačů budou chtít tyto funkce ve svém kódu zachovat, protože sdílejí ovladače mezi 2.4 a 2.6. Ale Greg odpověděl: Všechny ovladače by měly být v hlavním stromě, tak proč by to potřebovaly? Ovladače mimo strom jsou každý za sebe... Adrian na to řekl:

Já ale mluvím o ovladačích v hlavním stromě jádra.

V některých případech podporuje autor jak 2.4, tak 2.6 a dává přednost tomu, aby byla ta podpora v jediném souboru. Čas od času pošle nejnovější verzi svého ovladače Linusovi nebo Marcelovi.

Když ty atrapy globálních funkcí odstraníš, přinutíš všechny správce ovladačů, kteří takhle pracují, aby je dali do svých ovladačů.

Vím, že je hodně míst, kde nejsou 2.4 a 2.6 kompatibilní z dobrých důvodů. Ale je-li udržení kompatibility mezi 2.4 a 2.6 v některých oblastech tak snad né, že stačí podržet hlavičkový soubor s pár atrapami funkcí, stojí to za úvahu.

A když se to všechno ponechá v jednom souboru místo rozházení po celých zdrojácích jádra, bude za pár let daleko snazší poslední výskyty vyčistit.

Christoph Hellwig k tomu řekl: DevFS volání pro 2.4 a 2.6 jsou totálně nekompatibilní. Takže nejjednodušším způsobem podpory jak 2.4, tak 2.6 v této oblasti je: přestat podporovat devfs. Stejně bylo pořád označené jako experimentální nebo zastaralé. Adrian byl překvapen tím, kolik se toho v DevFS změnilo během 2.5, a stáhl své připomínky.

Na jiném místě poslal Greg s předmětem "[PATCH] Odstranění devfs z kódu oddílů" patche, které DevFS odstraňovaly nejen z kódu oddílů, ale odevšad.

V tomto vláknu vyjádřil Armin Schindler své překvapení nad tím, že bude odstranění provedeno uprostřed stabilní řady... Adrian mu připomněl: Podle současného vývojového modelu je 2.6 vývojovým jádrem... A Ed Tomlinson připojil Aktuální Linusův kernel je 2.6.11.12, kde poslední .12 značí, že jde o poslední 2.6.11 s aplikovanými VIF (very important fixes = velmi důležité opravy). Armin reagoval s tím, že si toho je vědom, ale přesto ho překvapuje, že se podobné pozdvižení děje bez zvýšení druhého čísla verze.

Linux 2.4 nebude podporovat GCC 4, 2 e-maily

12. črv - 13. črv

Mikael Pettersson napsal:

Tahle sada patchů opravuje problémy s gcc4 v kódu "jádra" jádra 2.4.31. Provozuji 2.4 jádra kompilovaná pomocí gcc4 už několik měsíců na i386, x86_64 a ppc32 a v současné době při srovnání s gcc34 nic nechybí.

Poznámka: používejte raději čerstvý gcc-4.0.1, protože o gcc-4.0.0 se ví, že nefunguje správně.

Tato sada neobsahuje opravy ovladačů, souborových systémů a architektur, které sám nepoužívám. Mám pro tento účel předběžný patch kit, ale protože se mu dostalo jen omezeného kompilačního testování, nebudu ho posílat, nebudou-li přijaty tyto hlavní patche.

Marcelo Tosatti odpověděl: Řekl bych, že už je čas začít tento druh úprav zamítat. Mohou žít mimo hlavní repozitář.

Linuxová dokumentace, kterou lze prohlížet jen v nelinuxových prohlížečích, 10 e-mailů

14. črv - 16. črv

Nick Newcomb napsal:

Pracuji v Software Revolution a říkal jsem si, že by vás mohlo zajímat, že jsme právě dokončili automatické generování dokumentace k linuxovému jádru a příbuzným subsystémům na úrovni designu. Dokumentace je složena z prolinkovaných obrázků a textových dokumentů pro všechny hlavní sybsystémy a všechna pole i funkce zdrojového kódu. Organizována je podle spletitosti a umístění v souborovém systému. Zahrnuje linuxové jádro, správu paměti, souborové systémy, bezpečnost, šifrování, inicializaci, ovladače, architekturu a subsystémy pro komunikaci mezi procesy. Kromě toho ji nabízíme za... no, zadarmo. Myslím, že byste ji mohli využít. Pokud si to chcete prohlédnout, jděte na:

http://www.softwarerevolution.com/jeneral/open-source-docs.html

Parag Warudkar řekl, že by tu dokumentaci rád používal, ale stránky jsou přístupné pouze s pluginy pro Windows. Několik ostatních lidí mělo podobné potíže a probírali možná řešení. Kyle Moffett mohl stránky prohlížet v Mac OSX a velmi se mu líbily, ale všiml si, že používají hodně obrázkových map [imagemap]. Navrhl, aby to změnili, což by jeho oblíbeným prohlížečům OmniWeb a Safari usnadnilo práci.

---

V originálu Kernel Traffic 316 vyšla navíc ještě tato témata:

• Linux 2.6.12-rc6-mm1 Released
• PREEMPT_RT Versus Adeos: A First Problematic Comparison
• Linux 2.6.11.12 Released

Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.

Diskuse k tomuto článku

[Michal Čihař]

Odkaz na obrázek [4] je špatně, je tam mezera před jpg.

[Leoš Literák]

opraveno

[Michal Kubeček]

Podobný problém je ještě u odkazu [2].

[Robert Krátký]

Opraveno.

[Trained.Monkey]

Diky za dobry preklad

[Robert Krátký]

Díky za ty díky, ale musím říct, že tentokrát jsem byl dost zklamaný, protože se mi nepodařilo přeložit "kernel stacks".

[bhy]

Slovo "stack" je zrádné.. taky se s ním při překladech potýkám. Že by "jaderné zásobníky?" :)

[Mak]

Cim to, ze nam z cestiny pomalu mizi neshodne privlastky? To uz se to na zakladnich skolach neuci?

[bhy]

Tak teď přiznávám, že jste mě dokonale zmátl. Myslíte jako "zásobníky jádra" místo "jaderné zásobníky?" Jo, to by asi bylo lepší, jako "patenty na software" místo "softwarové patenty" (o těch když jsem překládal článek, tak mi bylo v podstatě nařízeno překládat "software patents" jako "softwarové patenty," ale nijak to necením).

[egg]

Ve filmu Nejistá sezona Smoljak říká: "Já si snad na to ramínko napíšu ramínko režiséra." Následuje krásná citace z dopisu vysvětlujícího, proč je režisérovo ramínko více česky:

Až půjdu přes Most Karla, do Divadla národa na Stěnu čerta, budu vědět, že jste zvítězili. Ale upozorňuji Vás, že to bude vítězství Pyrrhy. (dříve Pyrrhovo vítězství)

[Michal Kubeček]

Nechce se mi to dohledávat, ale opravdu tam má být 4Kb? Není to spíš 4KB?

[tim kutil taylor]

v tom pripade '4 kB', KB je KelvinByte

[Ondra 'Kepi' Kudlík]

> Pokud ne, budou se možná lidi, kteří používají Reiser4, rozhodnout, jestli změnit souborový systém nebo architekturu...

asi by to chtělo "muset rozhodnout" nebo tak něco....

> Já ale mluvím o ovladačích v hlavním stromě jádra.

"stromu" jádra??

Neberte to jako kritiku, jen přidávám svou trošku do mlýna, aby byl článek kvalitnější. Díky moc za něj!

[bhy]

> "stromu" jádra??

Takže "na stromě" ale "ve stromu"? Tvar šestého pádu se liší podle konkrétní předložky? Nebo má být i "na stromu?"

Jen si tak rýpu, neberte to zle :)

[David Jaša]

jj, čeština je bohatý jazyk.

[ignac]

hmm, zacnite pisat po slovensky a nemate problem :)))))))

[cronin]

Heh, by si sa čudoval: na konkrétny príklad si nespomeniem, ale aj v slovenčine existujú podstatné mená, ktoré sa v jednotnom čísle skloňujú podľa vzoru dub a v množnom podľa vzoru hrdina (alebo naopak?). A potom aby sa v tom človek vyznal.