Jaderné noviny 321

9. 9. 2005 | Robert Krátký | Jaderné noviny | 4455×

Návod k používání prázdného místa ve zdrojových kódech. RelayFS bude pravděpodobně začleněn. Přidání podpory hotswap do libata. Diskuze o tom, jak mohou uživatelé sledovat verze jádra.

Návod k používání prázdného místa ve zdrojových kódech, 38 e-mailů

11. črc - 22. črc

Michael S. Tsirkin napsal:

Dostal jsem za úkol obeznámit několik nových zaměstnanců se stylem psaní kódu v linuxovém jádře. Sice máme Documentation/CodingStyle, ale to vynechává podrobnosti, které mají být pochopeny díky studiu příkladů v samotných zdrojových kódech.

A protože jsem se díky tomu sám několikrát spálil, než jsem všechno pochytil, dal jsem dohromady krátký seznam pravidel doplňujících Documentation/CodingStyle.

Připojil odkaz na svůj seznam pravidel a několik lidí se ozvalo s více či méně podivnými návrhy na úpravy.

RelayFS bude pravděpodobně začleněn, 89 e-mailů

11. črc - 25. črc

Tom Zanussi řekl Andrew Mortonovi:

Mohl bys prosím začlenit relayfs? Umožňuje logování a bufferování s nízkou režií, které v současné době v jádru nejsou.

Kód relayfs byl v -mm více než tři měsíce po rozsáhlém testování, které proběhlo na LKML počátkem roku, kdy jsme adresovali všechny připomínky, které lidé měli. Od té doby bylo k původnímu kódu potřeba přidat je pár drobných patchů, většinu z nich poslali uživatelé. Těm, kdo si našli čas, aby poslali patche nebo upozornili na problémy, bychom rádi poděkovali.

Kód v -mm byl také nemilosrdně testován a nenarazili jsme na žádné problémy - vypadá velmi stabilně.

Také jsme se pokusili zařídit to tak, aby bylo pro lidi co nejsnazší vytvářet "rychlé a nepěkné" (nebo pořádnější) jaderné logovací aplikace. Připojuji odkaz na příklad, který ukazuje, jak to může být užitečné. V kostce: využívá logovací funkce relayfs ke sledování kmalloc/kfree a odhalování paměťových úniků. Jediná věc, kterou to dělá v jádře, je logování malého binárního záznamu pro kmalloc i kfree. Data jsou pak zpracována v uživatelském prostředí jednoduchým perlovým skriptem. Ukázku výstupu a samotný příklad najdete zde:

http://relayfs.sourceforge.net/examples.html#kleak

V neposlední řadě je kód také malý (40k zdrojáků), "soběstačný" [self-contained] a neobtěžuje zbytek jádra.

Abych to shrnul: relayfs je velmi stabilní, užitečný svým současným uživatelům a po začlenění bude užitečný mnoha dalším. Napadá-li tě něco, co jsme přehlédli, nebo na čem bychom měli pracovat, aby se relayfs dostal do podoby vhodné k začlenění, dej nám prosím vědět.

Andrew řekl, že proti tomu nic nemá, ale zeptal se: Měli byste čas sestavit seznam existujících a plánovaných aplikací? Dave Airlie odpověděl:

Mám v plánu to použít pro něco, o čem zatím nikdo neví.

Chystal jsem se to využít pro debuggovací logovač DRM paketů... Když chci zkusit vystopovat zamrzání systému, printk moc nepomůže, protože to systém natolik zpomalí, že se problémy přestanou vyskytovat. Už jsem k tomu napsal nějaký základní kód a doufám, že budu moci využít trochu pracovního času, abych to dokončil.

Baruch Even také napsal: Používám relayfs při vývoji k logování aktuálních parametrů TCP stacku [haldy] a časovacích informací. Rád bych, aby byl relayfs začleněn. A Tom dodal:

Vím, že systemtap (http://sourceware.org/systemtap/) používá relayfs a LTT (http://www.opersys.com/ltt/ index.html) je právě přepracováváno tak, aby jej využívalo.

Já sám bych si chtěl začít hrát s vytvářením nějakého vizualizačního nástroje využívajícího data získaná z relayfs. Doufám, že na to budu mít více času, bude-li relayfs začleněn .

Na jiném místě poznamenal Christoph Hellwig, že kód vypadá velmi dobře. A poblíž řekl Andrew, že je nakloněn začlenění i bez velkého počtu uživatelů, protože relayfs je podle mě spíše pro aplikace "v jádře" než pro uživatelské prostředí.

Přidání podpory hotswap do libata, 7 e-mailů

21. črc - 28. črc

Lukasz Kosewski napsal:

Tato série patchů přidá do libata rámec pro umožnění přidávání a odebírání disků za chodu [hot-swapping].

Jsou to tři patche:
01-promise_sataII150_support
02-libata_hotswap_infrastructure
03-promise_hotswap_support

Budu rád za vaše připomínky a příspěvky k designu. Pokud někdo vidíte problémy se souběžností, navrhněte opravy.

Zatím jsem patche HODNĚ testoval s jádrem 2.6.11.12 + 2.6.11-libata-dev1.patch. S tímto jádrem jsem nepřišel na žádné závažné problémy. Všechno testování probíhalo s řadiči Promise SATA150 a SATAII150 Tx4/Tx2 Plus a velkým množstvím různých Western Digital a Seagate disků.

Patche jsem portoval na 2.6.13-rc3 a 2.6.13-rc3-mm1, na kterém jsem je také testoval. Fungovaly stejně jako ty oproti 2.6.11, až na chyby v SCSI vrstvě.

Patche, které připojím, budou aplikovatelné na 2.6.13-rc3-mm1, protože předpokládám, že než se lidi dostanou k tomu, aby se jimi vážně zabývali, budou už stávající libata patche z toho stromu v hlavním jádře. Pokud to není správný způsob, řekněte mi prosím, oproti které verzi jádra bych měl patche připravit.

Jeff Garzik odpověděl: Dost dobrý! Jakmile dokončím SATA ATAPI (tento týden), podívám se na to. Rychlý pohled na patche však neodhalil nic hrozivě špatného :). Navrhl poslat kopii mailu i do konference linux-ide k další diskuzi a Lukasz patche do této konference přeposlal. Mezitím se Doug Maxey nabídl, že pomůže s testováním, za což byl Lukasz velmi vděčný.

Diskuze o tom, jak mohou uživatelé sledovat verze jádra, 8 e-mailů

25. črc - 27. črc

Gene Heskett hlásil: Právě jsem zkompiloval jádro, o kterém jsem si myslel, že to je 2.6.12.3, ale můj skript se roznemohl, protože jsem nezkontroloval EXTRA_VERSION v Makefile, která byla nastavena .2 patchem u verze .2. Teď budu muset své 2.6.12 moduly překompilovat :(. Tak jaké je správné pořadí pro kompilaci 2.6.12.3? Brian Gerst odpověděl: Tyhle verze nejsou inkrementální. Každá se aplikuje na základní 2.6.12 strom. Kurt Wall řekl: Tohle se mi také před časem stalo. Pošlu patch, který na to v hlavním README upozorní. Steven Rostedt doplnil:

Někdo by měl také opravit stránku kernel.org, protože na ní není odkaz na plné jádro 2.6.12. A vzhledem k tomu, že hodně patchů na té stránce je přímo proti 2.6.12 a ne 2.6.12.3, bylo by fajn mít možnost získat z hlavní strany i tuhle verzi.

Pokud chci inkrementálně zkompilovat 2.6.13-rc3-mm1, potřeboval bych stáhnout balík s 2.6.12, potom patch 2.6.13-rc3 a nakonec je všechny v tom pořadí aplikovat? Jestli ano, tak mohu získat všechny kroky kromě prvního a základního. Jo, mohl bych také stáhnout plnou verzi kteréhokoliv z těch novějších, ale stejně mi připadá, že by dávalo smysl na hlavní stránce ten počáteční bod ponechat.

Valdis Kletnieks připojil: A ještě další dobrý důvod je, že až vyjde 2.6.13, bude vydán patch oproti 2.6.12, ne 2.6.12.N. Což znamená, že byste museli stáhnout balík 2.6.12.N a patch 2.6.12.N a pak provést patch -R a *potom* aplikovat patch 2.6.13.

---

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

• Linux 2.6.13-rc3-mm1 Released; Some Consideration Of CKRM
• Adding -Wundef To CFLAGS During Kernel Compilation
• Some Developer Disconnect Over Touchscreen Support For Sharp SL-5500
• Importing Older Kernel History From BitKeeper To git
• Linux 2.4.32-pre2 Released

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

       

Komentáře

[Michal Marek (twofish)]

kernel guide to space AKA a boring list of rules:

4. Indentation rules for C
	Use tabs, not spaces, for indentation. Tabs are 8 characters wide.

[Josef Kufner]

Tabulator je fajn, ale u vic vnorenych casti kodu to je precejenom odsazeni o moc, takze se tab nastavi na 4 znaky a je to idealni

[Voidless]

A Linus odpovida:

Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.

Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.

[VícNežNic]

Což ovšem funguje pro C, ale PokudNěkdoPoužívá.něcoTakového (), tak to je složitější…

[zabza]

občas stačí GTK+, aby byly všecky řádky dlouhý jak nudle z nosu

[Leoš Literák]

presne tak. A java se treba snazi pozuivat identifikatory a nazvy metod, ktere tvori cela slova. Zadne strcmp, strcpy apod. Takze s 8 znakovou indentaci bych nepochodil.

[Michal Kubeček]

Chyba je IMHO v tom, že se někdo snaží bezmyšlenkovitě zobecňovat pravidla pro formátování zdrojáků jádra na aplikační software nebo dokonce na jiné jazyky než C. Protože jakkoli je zdůvodnění toho jaderného coding style logické a smysluplné, některé podstatné části jsou velmi specifické právě pro to jádro a pro aplikační software (nebo dokonce jiné jazyky) příliš neplatí.

[Josef Kufner]

Joo, na tom něco je, ale občas to prostě víc vnoření chce... nestává se to často, ale občas jo

[Jiří (BoodOk) Kadeřávek]

Predpokladam, ze Linus nerad XML, pokud nerad taby mensi nez 8ch.

[VícNežNic]

A tak to má být. A nejenom for C.

[iSteve]

Hotswap, ne hotwswap:)

[Robert Krátký]

Dík.