Portál AbcLinuxu, 25. dubna 2024 05:30
Aktuální verze jádra: 2.6.19-rc5. Citát týdne: Andrew Morton. S čítačem taktů se počítá. Úmyslné zavádění chyb do jádra. Svobodný ovladač pro Atheros.
Aktuální předverze řady 2.6 je stále 2.6.19-rc5; během posledního týdne nebyly vydány žádné nové -rc. Do hlavního git repozitáře si však našlo cestu dost patchů na to, abychom se před finální verzí dočkali ještě 2.6.19-rc6.
Aktuální verze -mm stromu je 2.6.19-rc5-mm2. Mezi nedávné změny patří možnost vkládat do jádra chyby (vizte níže), kvalifikace založené na souborech a zpětný port rezervačního kódu z ext3 na ext2.
Pro uživatele 2.6.16 vydal Adrian Bunk s množstvím oprav verzi 2.6.16.32.
70 % narazilo na chybu
1/7 si myslí, že se to zhoršuje
1/4 si myslí, že reakce LKML je nedostatečná
3/5 si myslí, že reakce na bugzillu je nedostatečná
2/5 si myslí, že nemáme dobře nastaven poměr funkce : stabilita
2/3 narazily na chybu; 1/3 z nich zůstává neopravena
1/5 uživatelů je v současné době ovlivněna chybou v jádře
Spokojen?
Čítač taktů (procesoru) [time stamp counter (TSC)] je hardwarová funkce, kterou najdeme na většině současných procesorů. Je to speciální registr, který je navýšen s každým taktem. Protože takt je z pohledu procesoru základní časovou jednotkou, TSC poskytuje nejpřesnější časovací informace, které má daný procesor k dispozici. Lze jej tedy využívat pro mnoho aplikací - například měření přesné doby trvání specifických instrukcí nebo operací.
TSC lze také rychle číst (konec konců je to jen registr procesoru), takže je zajímavý i pro udržování systémových údajů o čase. Hodně aplikací často kontroluje čas; dokonce tolik, že gettimeofday() je jedno z výkonnostně nejdůležitějších systémových volání v Linuxu. Použije-li se TSC k interpolaci v rámci rozlišení běžných hodin, může dát systém přesný čas, aniž by to hodně času zabralo.
Taková je aspoň teorie. V praxi se však ukazuje, že je velmi obtížné takovým způsobem TSC používat. Změní-li se frekvence procesoru (což se děje u procesorů, které mění svou spotřebu energie), změní se i rychlost TSC. Je-li procesor zastaven (může se stát při nečinnosti), může se zastavit i TSC. Na víceprosorových systémech se od sebe mohou TSC na jednotlivých procesorech časem odchýlit - což vede k situaci, kdy by si proces mohl přečíst čas na jednom procesoru, pak se přesunout na druhý a narazit na dřívější časový údaj, než jaký si přečetl na prvním.
Přes tyto problémy se linuxové jádro snaží TSC využít co nejlépe. Kód, který pracuje s TSC, obsahuje několik kontrol, jež se snaží odhalit situace, kdy by čas založený na TSC nemusel být spolehlivý. Jedna z těchto kontrol porovnává TSC čas s počtem jiffies, který je navyšován prostřednictvím "tiků" časovače. Je-li po deseti vteřinách tiků počet TSC taktů odlišný od očekávané hodnoty, usoudí jádro, že TSC není stabilní a přestane ho používat pro informace o čase.
Pokud se do hry vloží ještě patch implementující dynamický tik, začnou se dít zajímavé věci. S dynamickými tiky je periodické časovačové přerušení vypnuto vždy, když není v nejbižší budoucnosti nic na práci, což procesoru umožňuje zůstat déle nečinný a spotřebovat méně energie. Jakmile se však něco stane, musí být hodnota jiffies aktualizována, aby odrážela prošvihnuté tiky časovače - a to se obyčejně dělá pomocí získání časového údaje z jiného zdroje. V lepším případě tato série událostí vyřadí z provozu test, který má zajistit, aby TSC fungovalo stabilně; v horším případě to povede k poškození systémového času. Nic dobrého.
Z tohoto důvodu obsahuje nedávno aktualizovaná sada patchů s časovači s vysokým rozlišením a dynamickým tikem změnu, která vypíná používání TSC. Vypadá to, že časovače s vysokým rozlišením a dynamický tik jsou funkce, které s TSC nejsou kompatibilní - a při konfiguraci jádra bude nutné si vybrat buď jedno nebo druhé. Protože TSC velmi pomáhá výkonnosti, vypnutí se samozřejmě některým lidem nelíbilo. A to do té míry, že by raději časovačové patche do jádra zatím nepřijímali.
V reakci na stížnosti Ingo Molnar vysvětlil:
Jen jsme si uvědomili, že během posledních 10 let nebyla napsána žádná obecně funkční gettimeofday založená na TSC (a byl jsem to já, kdo napsal první verzi pro Pentium, takže je to i moje chyba), a že by nám bylo lépe bez ní. Dokáže-li někdo dát dohromady funkční implementaci gettimeofday() založenou na TSC, nebudeme mít nic proti.
Ingo také napsal testovací program, který ukazuje, že časové nesrovnalosti jsou na systémech s TSC běžné - přinejmenším na víceprocesorových systémech.
Arjan van de Ven navrhl provizorní řešení, které by mohlo fungovat dostatečně dobře na to, aby iluze zůstala zachována. Spočívá v nastavení offsetů a násobičů pro TSC každého procesoru. S pomocí offsetů (které by mohly kompenzovat odchylky TSC mezi procesory) a násobičů (které by prováděly úpravy podle změn frekvence) by se dalo udržovat jakési zdání synchronizovaného a přesného TSC času - za předpokladu, že by jádro mohlo detekovat TSC události a zmíněné hodnoty odpovídajícím způsobem upravovat. Zatím se však neobjevil žádný kód, který by tento nápad implementoval.
Diskuze se vytratila bez zjevného rozuzlení, i když ke konci Thomas Gleixner připustil, že úplné zrušení TSC bylo přehnané. Místo toho pracuje na řešení, které by systému zabránilo v přechodu do režimu dynamického tiku, pokud není k dispozici jiný spolehlivý časovač. Až bude kód zveřejněn, mělo by být možné mít celou sadu: časovače s vysokým rozlišením, dynamický tik i rychlé hodiny používající TSC.
Někteří vývojáři mají nepochybně pocit, že jejich systémy nefungují dost už samy od sebe; určitě by nehledali způsoby, jak způsobit více potíží. Jiní se však zajímají o to, jak se jejich kód chová, nastane-li problém. Jak nedávno ke své značné nelibosti zjistil Jonathan Corbet, chybové chování bývá mnohem těžší debugovat než "normální" kód. Můžeme se snažit předvídat selhání a napsat správnou reakci, ale otestovat takový kód je dost složité. Takže řešení problémů může být nesprávné (nebo úplně chybět), ale kód se bude tvářit, že funguje - dokud se něco nepokazí.
Ve snaze pomoci jádru lépe řešit chyby pracuje Akinobu Mita už nějaký čas na systému pro zavádění chyb do běžícího jádra. Tím, že způsobí občasné potíže, by měl kód pro zavádění chyb pomoci zajistit, aby byly chybové situace řešeny - a správně. Tento mechanismus si našel cestu do 2.6.19-rc5-mm2, kde jej budou, doufejme, vývojáři využívat k testování, jestli je jejich kód neprůstřelný. Doufejme.
Systém dokáže způsobit selhání alokací paměti na dvou úrovních: ve slab alokátoru (kde má vliv na kmalloc() a většinu ostatních alokací malých objektů) a na úrovni alokátoru stránek (kde nakonec ovlivní vše). Součástí jsou také háčky [hooks], které mohou způsobit občasné selhání diskových I/O operací, což by se mělo hodit vývojářům souborových systémů. Pro oba případy existuje pružná konfigurační infrastruktura založená na debugfs umožňující nastavení za běhu. To vývojářům dovolí zaměřit zavádění chyb do specifických částí jádra.
Jonathan Corbet si se zapnutou podporou zavádění chyb zkompiloval 2.6.19-rc5-mm2. Z nějakého důvodu konfigurační systém požadoval zároveň zapnutí validátoru zamykání; někdo možná zavedl chybu do config skriptů. Výsledné jádro každopádně exportuje adresář (v debugfs) pro každou dostupnou možnost zavedení chyby.
Takže například selhání alokace slabu je reprezentováno adresářem failslab. Při bootu systému je zavádění chyb vypnuto; selhání slabu je možné zapnout zapsáním celočíselné hodnoty do souboru failslab/probability. Zapsaná hodnota bude interpretována jako procentuální pravděpodobnost, že daná alokace selže. Takže "5" způsobí selhání v 5 % případů. Pro situace, kdy je potřeba méně než 1 % (ale více než nula), je k dispozici samostatná hodnota interval, která výsledek dále filtruje. Takže 0,1 % selhání lze docílit nastavením interval na 1000 a probability na 100 - pokud možno v tomto pořadí. Pak je tu ještě proměnná times, která určuje horní hranici počtu simulovaných selhání.
Jak by se dalo očekávat, náhodné zavádění chyb do celého jádra nemusí vývojáři, kterého pravděpodobně zajímá chování určitého subsystému, přinést žádné užitečné informace. Selhávání běžných příkazů shellu, zatímco se snažíte něco provést v konkrétním ovladači, nejde vydržet moc dlouho. Proto existuje množství voleb, které lze použít k zaměření chyb na požadovanou část jádra:
Existují ještě další možnosti; například sada parametrů pro zapnutí zavádění chyb už při bootu, což se může hodit k debugování prvotní inicializace systému. Podrobnosti v souboru s dokumentací. V dokumentačním adresáři je také pár skriptů určených ke koncentraci chyb na specifický příkaz nebo modul.
Výsledkem toho všeho je užitečný nástroj. Není třeba pouze doufat, že si jádro s problémy poradí správně; teď je možné to nasimulovat a zjistit, co se stane. Mělo by to vést k lépe testovanému a robustnějšímu jádru, což je jen dobře.
Rodina bezdrátových čipsetů Atheros má své zastoupení v mnoha síťových adaptérech a noteboocích. Jde o flexibilní a schopné zařízení, která má jedinou nevýhodu: není pro něj svobodný linuxový ovladač. Podporu v Linuxu zajišťuje volně dostupný ovladač MadWifi, ale jeho jádrem je binární HAL modul [hardware access layer = vrstva pro přístup k hardwaru], který provádí většinu skutečné práce. Tento modul má všechny problémy obyčejně spojované s proprietárními ovladači: nelze jej zkontrolovat nebo opravit, nemůže být vylepšen, je k dispozici jen pro verze jádra a architektury podporované výrobcem atd. Ale pro uživatele Linuxu je na výběr buď MadWifi nebo nic.
Už dva roky je k dispozici svobodný HAL modul pro Atheros, který se jmenuje "ar5k". Napsal ho Reyk Floeter a používá ho OpenBSD. Jenže tento kód byl dlouho pronásledován tvrzením, že nebyl vyvinut nezávisle, a Atheros by si tedy mohl dělat nároky na jeho copyright. V současné atmosféře nechce nikdo riskovat zanesení potenciálně závadného kódu do jádra, protože případné důsledky by mohly být příliš vážné. Takže ačkoliv je i nadále velký zájem o podporu Atherosu v linuxovém jádře, existující HAL není brán v úvahu.
Ukázalo se však, že na problému se pracovalo tam, kde by to nikdo nečekal. Vývojáři ar5k požádali Software Freedom Law Center, aby vydalo prohlášení o tom, jestli jde o legitimní software nebo ne (z hlediska zákonu o copyrightu). 14 listopadu poskytlo SFLC svoji odpověď:
SFLC provedlo nezávislé vyšetřování v rámci týmu OpenBSD ohledně vývojové historie zdroje ar5k. Získané odpovědi poskytují přijatelný podklad k tomu, aby SFLC věřila, že vývojáři OpenBSD, kteří pracovali na ar5k, nezneužili kód, a že implementace ar5k je původní copyrightovanou prací OpenBSD.
Takové zjištění by mělo otevřít dveře k začlenění svobodného Atheros ovladače do linuxového jádra. Nejprve je však nutné vyřešit pár problémů.
Jedním z nich je všeobecný zmatek v linuxovém subsystému pro bezdrátovou komunikaci. Vývojáři stále chtějí přejít na stack Devicescape a dostat jej do jádra, ale v té oblasti ještě zbývá mnoho práce. Jenže nový ovladač bezdrátových zařízení, který nespolupracuje s Devicescape, bude mít cestu do jádra obtížnou. Pracuje se na přenesení MadWifi na Devicescape (nazýváno "DadWifi"), takže to by mohl být nejrychlejší způsob, jak podporu Atheros do jádra dostat.
Další potíž je, že kód založený na konceptu HAL bývá dost nepopulární. HAL je obyčejně vnímán jako nadbytečná abstrakční vrstva mezi hardwarem a ovladačem, která slouží jen k zamaskování toho, co se doopravdy děje, aniž by poskytovala nějakou výhodu. Takže vývojáři, kteří navrhují řešení založená na HAL, jsou většinou vypoklonkováni s tím, že se mají vrátit, až se HAL zbaví. Není důvod předpokládat, že by to v tomto případě bylo jinak.
Ale i kdyby nemohl být použit přímo, je teď kód ar5k k dispozici pro referenci a případnou adaptaci na linuxový ovladač. Dost vývojářů má o zprovoznění Atheros adaptérů zájem, takže šance, že tu práci někdo v (relativně) blízké budoucnosti udělá, jsou docela vysoké. Seznam zařízení nepodporovaných Linuxem by se měl zase zkrátit.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.