Jaderné noviny – 23. 11. 2011: Ovladače jako dokumentace

5. 12. 2011 | Luboš Doležel | Jaderné noviny | 3393×

Aktuální verze jádra: 3.2-rc2. Citáty týdne: Linus Torvalds, Alan Cox, Olav Vitters. Ovladače jako dokumentace. POSIX_FADV_VOLATILE.

Obsah

• Aktuální verze jádra: 3.2-rc2
• Citáty týdne: Linus Torvalds, Alan Cox, Olav Vitters
• Ovladače jako dokumentace
• POSIX_FADV_VOLATILE

Aktuální verze jádra: 3.2-rc2

Aktuální vývojovou verzí jádra je nadále 3.2-rc2; během uplynulého týdne nové předverze nevyšly.

Stabilní aktualizace: verze 3.0.10 a 3.1.2 vyšly 21. listopadu. Obě obsahují řadu důležitých oprav, i když tentokrát je jejich počet menší než jindy.

Stabilní aktualizace 2.6.32.49, 3.0.11 a 3.1.3 se v době psaní tohoto textu revidují; můžeme je očekávat po 25. listopadu.

Citáty týdne: Linus Torvalds, Alan Cox, Olav Vitters

Začleňuji kód během letu, protože prostě můžu. Co mám použít za časové pásmo?

-- Linus Torvalds (díky Cesaru Eduardu Barrosovi)

Fedora se teď stává natolik podivnou a závislou na zázračných initrd, že je v současnosti IMHO dost nepoužitelná pro vývoj jádra, protože se to tam nedá ladit.

-- Alan Cox

...naším cílem je nadále poskytovat desktop, který je ve výchozím stavu dobrý pro 99 % lidí, ale myslíme si, že pro ty, co rádi tuní své desktopy, by měl existovat snadný způsob, jak to udělat.

Všimněte si mých slov: těch 99 % nezahrnuje jaderné hackery. Nejsem si jist, jestli bychom se o tom neměli zmiňovat explicitně.

-- Olav Vitters; připravte se na blízké "Occupy LKML"

Ovladače jako dokumentace

Jako komunitu nás hodně zajímá kvalita kódu. Jaderný kód je prověřován z hlediska funkčnosti, dlouhodobé udržovatelnosti, dokumentace a ještě více. Kód ovladačů není vždy ověřován do takové hloubky, ale může být stejně důležitý – pokud nefungují naše ovladače, nefunguje ani naše jádro. Je tu jeden pohled na dlouhodobou udržovatelnost ovladačů, kterému by se mohlo věnovat více pozornosti: to, do jaké míry ovladač dokumentuje fungování hardwaru.

Mohli bychom se hádat, že dokumentování hardwaru má na starosti ten, kdo psal související datasheet. Na tomto tvrzení je trochu pravdy, ale v mnoha případech má k datasheetu přístup jen původní autor ovladače. Ti, kteří přijdou později, se mohou snažit vymámit dokumentaci z výrobce nebo hledat utajované kopie umístěné kdesi na síti. Ale mnohdy je jedinou možností pochopit hardware z jediného dostupného zdroje informací: stávajícího ovladače. Pokud zdrojový kód ovladače novému vývojáři nepomůže, mohli bychom se dohadovat, že původní autor zklamal očekávání.

Takže pokud ovladač obsahuje kód jako:

writel(devp->regs[42], 0xf4ee0815);

tak mu chybí něco důležitého. Při nedostupnosti datasheetu nemá žádný jiný vývojář šanci tušit, co ta operace vlastně provádí.

Tento problém je ale ještě horší; datasheety často vynechávají užitečné informace, zakrývají pravdu a lžou, jak když tiskne. Nejtěžší věci na rozcházení hardwaru je často procedura zjišťování, jaké vlastnosti hardware má a co má za speciální potřeby. Často to vypadá, že datasheet byl napsán ještě než byl navrhnut hardware. Jak čas utíká, začíná se lépe chápat problém a termíny se blíží, tak návrháři hardwaru začínají zahazovat funkce, které už nejde stihnout, nebo ty, které podle svého vlastní názoru, proti kterému není odvolání, lze snadno dořešit v softwaru. K aktualizaci datasheetu podle výsledného hardwaru nikdy nedojde.

Pozorní vývojáři, jakmile odhalí imaginární podstatu určité hardwarové funkce, přidají do ovladače komentář; díky tomu pak žádný budoucí správce kódu nemusí zjišťovat (tím obtížnějším způsobem, který znamená otisky klávesnice na čele), proč ovladač nevyužívá určité specifické, na pohled užitečné schopnosti hardwaru.

Pak je tu záležitost „vyhrazených“ bitů. Ještě nikdy nevznikl datasheet, který by obsahoval něco jako:

Registr podivných podružných funkcí (offset 0xc8)
Bit	Význam
17	Vyhrazeno: nedotýkat se, nebo teroristi vyhrají

Někde hluboko v nitru společnosti budou nanejvýš dva inženýři, kteří vědí, že dokumentace je nekompletní, ale nikdo se nikdy nedostal k tomu, aby ji aktualizoval. Pokud jednoho z nich dokážete zahnat do kouta, typicky je dotlačíte k tomu, aby uznali, že tento bit by měl být zdokumentován takto:

Registr podivných podružných funkcí (offset 0xc8)
Bit	Význam
17	0 = DMA engine se náhodně zasekává 1 = DMA engine funguje dle očekávání Výchozí hodnota = 0

Vývojář, který nemá možnost chytit aspoň jednoho návrháře hardwaru pod krkem, pravděpodobně stráví spoustu času bádáním, než zjistí, že musí nastavit bit „začni fungovat“. Toto úsilí může zahrnovat zpětné inženýrství proprietárních ovladačů nebo v případech čirého zoufalství nastavování náhodných bitů, aby zjistil, co se změní. Jakmile je kýžený bit nalezen, je přirozené, že jej těžce zkoušený a frustrovaný vývojář tiše nastaví, než vyrazí ven ve snaze vynulovat veškerou paměť o celé proceduře metodou aplikace velkých objemů piva. Vývojář, který obzvláště myslí na budoucnost, si může udělat do tištěné verze datasheetu poznámku.

Rukou psané poznámky nebývají užitečné pro dalšího vývojáře, který musí na ovladači pracovat. Chvilka strávená dokumentováním bitu:

#define WTF_PRETTY_PLEASE  0x00020000 /* Vždycky to nastavte, nebo se to zasekne */

může ušetřit někoho dalšího od hodin zbytečné bolesti.

Člověka to svádí myslet si o dokončeném ovladači, že je hotovo. Ale kód ovladače je stejně jako každý další jaderný kód předmětem neustálých změn. Musí se řešit změny API jádra, musí se opravovat problémy a je třeba podporovat nové verze hardwaru. V závislosti na tom, o jaké množství piva šlo, původní autor si může vzpomenout na zvláštnosti daného zařízení, ale ti, kdo jej následují, nikoliv. Všichni by na tom byli lépe, kdyby ovladač zajistil nejen fungování hardwaru, ale také umožnil čtenáři pochopit, jak hardware funguje.

Obvykle není těžké toho dosáhnout. Stačí definovat popisná jména registrům, bitům a polím namísto natvrdo napsaných konstant. Upozornit na vlastnosti nedostatečně popsané, nesprávně popsané nebo naprosto smyšlené. Okomentujte operace, které mají neobvyklé požadavky na pořadí nebo spolu nefungují správě. A obecně piště kód se značnou dávkou ohleduplnosti pro lidi, kteří budou muset v budoucnosti do vaší práce zasahovat. Některý hardware nelze nikdy řádně zdokumentovat, protože relevantní informace prostě nejsou dostupné; vizte například tento článek z roku 2006. Ale informace, které jsou dostupné, by měly být dostupné všem.

Hackeři kolem nitra jádra někdy dělají opovrhující poznámky o vývojářích ovladačů a práci, kterou dělají. Ale ti, kdo ovladače píší, mají před sebou často nelehký úkol spojení s množstvím detektivní práce; to oni tuto práci odvedou a pro nás hardware rozchodí. Psaní ovladačů, které adekvátně dokumentují hardware není přehnaným požadavkem; mají znalost hardwaru a potřebné schopnosti. Obtížnější může být žádat ty, kdo kód revidují, aby trvali na odvedení tohoto dodatečného úsilí. Bez tlaku ze strany revidujících mnoho ovladačů nikdy neumožní čtenářům skutečně pochopit, co se děje.

POSIX_FADV_VOLATILE

Cachování hraje důležitou roli snad na všech úrovních soudobého operačního systému. Bez možnosti cachovat často vyžadované objekty v rychlejší paměti utrpí výkon; stejná věc platí, ať člověk hovoří o individuálních blocích v cachi procesoru nebo obrázcích cachovaných procesorem. Ale ke cachování jsou třeba prostředky; tuto potřebu je nutné vyvažovat s ostatními žádostmi o stejné prostředky. Jinými slovy, někdy je nutné cachovaná data zahodit; často lze zlepšit výkon, pokud program vykonávající cachování může říci, co se může uvolnit z cache. nedávný patch od Johna Stultze se snaží aplikacím usnadnit nabízení cachí k uvolnění, jakmile začne být nouze o paměť.

Johnův patch se inspiruje u zařízení ashmem, které pro Android implementoval Robert Love. Ale ashmem se chová jako zařízení a dělá svou vlastní správu paměti, což komplikuje jeho začlenění do upstreamu. Johnův patch se místo toho snaží věci integrovat hlouběji do jaderného subsystému pro správu paměti. Takže má podobu nové sady voleb pro systémové volání posix_fadvise(). Především pak může aplikace označit rozsah stránek jako „volatilní“ pomocí operace POSIX_FADV_VOLATILE. Takto označené stránky může jádro odhodit, pokud začne docházet paměť. Zejména lze odhodit i špinavé stránky – bez zpětného zápisu – pokud byly označeny jako volatilní [velmi proměnlivé]. Tato operace se liší od POSIX_FADV_DONTNEED v tom, že dané stránky nebudou (obvykle) odstraněny ihned – aplikace může v budoucnu potřebovat obsah volatilních stránek, ale zvládne to, pokud zmizí.

Pokud se později stane rozsah stránek důležitým, aplikace by měla použít operaci POSIX_FADV_NONVOLATILE pro odstranění příznaku „volatility“. Návratová hodnota z této operace je důležitá: nenulová hodnota od posix_fadvise() značí, že jádro odstranilo jednu nebo více stránek z vymezeného rozsahu, zatímco byl označený jako volatilní. Toto je jediný náznak, který aplikace dostane o tom, že jádro přijalo její nabídku a vyčistilo některé volatilní stránky. Pokud tyto stránky odstraněny nebyly, posix_fadvise() vrátí nulu a cachovaná data budou aplikaci dostupná.

Existuje také operace POSIX_FADV_ISVOLATILE pro zjištění, zda byl daný rozsah označen jako volatilní, nebo ne.

Rik van Riel se ohledně tohoto zeptal na několik věcí. Vyjádřil obavy, že jádro může odstranit jedinou stránku z objektu nacachovaného přes několik stránek, čímž odrovná cachování, a přitom nezíská všechnu paměť použitou pro cachování daného objektu. Ashmem zjevně provádí vlastní správu paměti i proto, aby nedošlo k právě této situaci; jakmile je použita paměť objektu, je zabrána celá. John by se zjevně raději vyhnul přidávání seznamu typu „použito nejdál v minulosti“ do jádra, ale odpověděl v tom smyslu, že může být možné přidat logiku, která zabere celý volatilní rozsah, jakmile je z rozsahu vyjmuta jediná stránka.

Rik měl také obavy kvůli režii spojené s tímto mechanismem a navrhl alternativu, o které zjevně nějakou dobu přemýšlel. V tomto schématu by aplikace mohly otevírat (a předávat poll()) speciální popisovač souboru, který by obdržel zprávu, kdykoliv by jádro mělo nedostatek paměti. Od aplikací by se čekalo, že uvolní veškerou paměť, bez které se obejdou. Tento mechanismus je docela jednoduchý, ale v reálu by se pak mohl stát obtížným. Jakmile aplikace obdrží zprávu „uvolni nějakou paměť“, první věcí, kterou asi bude muset udělat, je výpadek stránky v obsluze této zprávy – což je věc, která si vyžádá alokaci další paměti. Označení paměti předem a uvolnění přímo z jádra se může ukázat spolehlivějším.

Po nedávných diskuzích o frontswap asi ani nepřekvapí, že se nikdo neodvážil poukázat na jistou nemalou podobu mezi volatilními rozsahy paměti a transcendentní pamětí. Zejména se to pak dost podobá „cleancache“, které bylo zařazeno ve vývojovém cyklu verze 3.0. Jsou tu jisté rozdíly: 1) umístění stránky do cleancache ji nejprve odstraní z normální paměti, zatímco volatilní paměť může zůstat na místě a 2) cleancache postrádá rozhraní pro uživatelský prostor. Ale hlavní myšlena je stejná: požádat systém, ať uchová určitou paměť, ale umožnit mu paměť zahodit, pokud to bude nutné. Může se stát, že tyto dva mechanismy budou spolupracovat.

Ale jak bylo řečeno, nikdo neměl odvahu tuto myšlenku zmínit a váš redaktor by si to jistě netroufl.

Další otázkou, která nebyla diskutována, je, zda by tento kód nemohl nakonec nahradit ashmem, čímž by se omezily rozdíly mezi hlavní řadou jádra a jádrem v Androidu. K takové náhradě by jistě nedošlo brzo; ashmem má své vlastní ABI, které bude muset být v jádrech Androidu podporováno po dlouhou dobu. V průběhu let by možná mohlo dojít k přechodu na posix_fadvise(), pokud by tomu vývojáři Androidu byli nakloněni. Ale nejprve se bude muset patch posix_fadvise() dostat do hlavní řady. Je to velmi nový patch, takže je těžké určit, zda nebo kdy k tomu dojde. Jeho nenásilná povaha a jasná potřeba této funkčnosti bude ale spíše hrát ve prospěch tohoto patche.

       

Komentáře

[xkucf03]

Sice nepíšu ovladače do jádra, ale tohle moc dobře znám:

Chvilka strávená dokumentováním bitu ... může ušetřit někoho dalšího od hodin zbytečné bolesti.

A nemusí jít jen o bity

[koudy]

Vy se neridite "Bylo to tezke naprogramovat, tak to musi byt tezke i pochopit?"

Nejlepsi jsou komentare ke kodu, ktere jsou zkopirovany s castmi kodu z jineho mista.

To pak tak "krasne" zprehledni a zjednodusi pochopeni.

[Sten]

Nejlepší komentáře jsou „Dirty hack“ bez vysvětlení proč a jak a „You’re not supposed to understand this“.

[Michal Kubeček]

Aspoň že tam není ještě "Neither do I." :-)

[cronin]

Pravdepodobne narážal na slávny komentár Knuth-a v zdrojákoch TeX-u pri premetoch s file deskriptorom 3.

[Sten]

Ten slavný komentář Donalda Knutha měl alespoň předtím popsáno, jak to funguje. Ale jsou i lidé, co si myslí, že jsou další Knuth, a tak to rovnou napíšou bez vysvětlivek :)

[olgo]

Jaderný kód je prověřován z hlediska funkčnosti, dlouhodobé udržovatelnosti, dokumentace a ještě více.

Pokud zdrojový kód ovladače novému vývojáři nepomůže, mohli bychom se dohadovat, že původní autor zklamal očekávání.

Jak čas utíká, začíná se lépe chápat problém a termíny se blíží, tak návrháři hardwaru začínají zahazovat funkce, které už nejde stihnout, nebo ty, které podle svého vlastní názoru, proti kterému není odvolání, lze snadno dořešit v softwaru.

[luta]

jo na te dokumentaci neco bude.. ono pak nepotesi najit v driveru komentar typu  /* magic number */

[Bluebear]

Zrovna komentář "magic number" mi připadá jako ještě poměrně stravitelný - to si interpretuju jako "nemám ponětí, co to dělá, ale dlouhým zkoumáním jsem zjistil, že tento registr musí mít vždy tuto hodnotu, jinak se to celičké po*ere"

[R]

Magicke cisla sa vyskytuju hlavne v driveroch, ktore vznikli bez dokumentacie, odchytavanim komunikacie binarneho drivera s HW. iekedy sa da zistit alebo odhadnut, co ktore cislo znamena (bity nejakeho registra alebo cisla prikazov). Niekedy nie a potom to ostane ako magicke cislo.