Jaderné noviny - 29. 8. 2007

6. 9. 2007 | Robert Krátký | Jaderné noviny | 3939×

Aktuální verze jádra: 2.6.23-rc4. Citát týdne: Robert Love. Kernel Summit 2007 - předběžný pohled. Pročištění API pro blokové ovladače. Další pokus o odstranění sysctl().

Obsah

• Aktuální verze jádra: 2.6.23-rc4
• Citát týdne: Robert Love
• Kernel Summit 2007 - předběžný pohled
• Pročištění API pro blokové ovladače
• Další pokus o odstranění sysctl()

Aktuální verze jádra: 2.6.23-rc4

Aktuální předverze je (k 29. 8. 2007) 2.6.23-rc4, vydaná 27. srpna (s kódovým označením "Prdící růžová lasička"). Obsahuje docela velkou hromadu oprav; "většina regresí" již byla vyřešena. Vizte podrobnosti v krátkém nebo dlouhém changelogu.

Od vydání -rc4 zatím nebyly začleněny žádné další patche. Minulý týden nevyšla ani žádná verze -mm.

Aktuální stabilní verze řady 2.6 je 2.6.22.5, vydaná 22. srpna. Opravuje přibližně 20 závažných problémů. Pracuje se na 2.6.22.6 (která bude mít dalších pár desítek patchů) a vydání už je trošku opožděné.

Starší jádra: 2.6.20.17 bylo vydáno 25. srpna s dlouhou řadou oprav. 2.6.20.18 vyšlo 28. srpna a odstraňuje dvě z těch oprav, protože se ukázalo, že jejich začlenění nebyl až zas tak dobrý nápad.

Citát týdne: Robert Love

Jinými slovy, zabrání poloviny procesoru není (překvapení!) moc dobré pro výkon multimédií. V tuto chvíli je zřejmé, že lidé, kteří se zabývají plánováním procesů, a vývojáři síťování se nesnášejí a nemluví spolu.

-- Robert Love (nemluvil o Linuxu)

Kernel Summit 2007 - předběžný pohled

V posledních několika letech se každoroční summit vývojářů jádra (jen pro zvané) konal těsně před Ottawským linuxovým symposiem. Letos to bude jinak: summit proběhne těsně po LinuxConf Europe v Cambridgi, UK. Jako obvykle tam bude i Jonathan Corbet z LWN, který bude posílat reportáže přímo z místa. Předběžný program již byl vystaven, stejně jako seznam účastníků (PDF). Máme tedy možnost se podívat na to, o čem se bude pravděpodobně diskutovat.

Před pár měsíci se v konferenci o summitu mluvilo o zajímavých tématech, která by mohla být na programu. Objevilo se množství obvyklých oblastí; v komunitě vývojářů jádra se pořád dějí zajímavé věci. Andrew Morton však u většiny témat namítal, že summit není tím správným místem, kde o nich mluvit:

Můj celkový náhled na jaderný summit: trávíme příliš mnoho času mluvením o technických věcech. K čemu je to však dobré? Technické debaty vedeme přes email a jde nám to dobře - a existuje dost důvodů, proč to dělat právě tak... A pak letíme přes půl světa, abychom dál tlachali o škálovatelnosti dentry keše? Toho mě ušetřete - víc bychom udělali doma.

Andrewův závěr, se kterým souhlasilo hodně dalších vývojářů, je, že diskuze o procesních otázkách jsou vždy zajímavější a užitečnější než technické záležitosti. Řeči o virtualizaci, správě paměti nebo ovladačích zařízení se vždy budou týkat jen malé skupiny a nejsou o moc přínosnější než práce přes email. Ale procesní věci se týkají každého a je mnohem těžší je řešit na dálku.

Takže letošní program se více týká vyšších úrovní vývojového procesu než v minulých letech. To však neznamená, že se o technických věcech nebude mluvit vůbec. Některé z těch techničtějších sezení se budou zabývat následujícími tématy:

• Zprávy z minisummitů. Jádro je velký program a vývojáři vědí, že problémy specifické pro určitý subsystém je lepší řešit v menších skupinách. V rámci summitu podají účastníci nedávných minisummitů (týkajících se přinejmenším správy napájení, souborových systémů, ukládání dat a virtualizace) zprávu ostatním.


• Na programu jsou otázky o real-time a plánovačích, protože je potřeba učinit několik velkých rozhodnutí. Ačkoliv si většina real-time stromu našla cestu do hlavního jádra, některé rušivější části (spící spinlocky, vláknové zpracovávače přerušení) zůstávají mimo. V hlavním jádře také není sada patchů se syslety/threadlety. Doufejme, že padnou rozhodnutí o tom, jestli mají být tyto funkce začleněny - a pokud ano, tak co je potřeba udělat pro to, aby byly v přijatelném stavu.


• Na vyřešení čeká také několik otázek ohledně správy paměti, včetně patchů s proměnnými stránkami a proměnnou velikostí bloků, možností předcházení zamrzání, práce na škálovatelnosti atd. Na programu je také spíše procesní otázka o tom, proč je tak těžké patche týkající se správy paměti dostat do hlavního jádra.


• Virtualizace z programu vypadla, protože většina práce na úrovni jádra v této oblasti už byla začleněna. Vývojáři kontejnerů se však teprve zahřívají a existuje mnoho otázek o tom, kam vlastně míří. Plná implementace kontejnerů by mohla znamenat výraznou režii - pro vývojáře i výkon - a možná by šla těžko prosadit.

To je z techniky asi vše; zbytek bude zaměřen na problémy vyšší úrovně. Summit začne diskuzí správců distribučních jader. Distributoři jsou z velké míry prvními uživateli jader, která vývojáři vydají; tito distributoři mají pak za úkol dostat vanilková vydání do stavu, který může být dodáván uživatelům. Správci distribučních jader bývají také první na ráně, když se něco pokazí; vždycky se dozvědí o všech problémech. Diskuze bude tedy příležitostí pro tyto správce promluvit si o kvalitě jader, která dostávají od vývojářů, a o postupech, jak situaci vylepšit.

Kdysi dávno bylo jádro osamělé a své služby systému prezentovalo formou systémových volání. V současných systémech však uživatelé vidí systém, který je tvořen celou řadou utilit, včetně knihovny C, udev, HAL atd. Vzájemná spolupráce těchto nízkoúrovňových komponent není vždy tak hladká, jak by bylo potřeba, a, navzdory velkému úsilí komunity vývojářů jádra, nové verze jádra občas způsobily, že utility jako udev nefungovaly. Setkání na téma "širší jaderný ekosystém" se bude zabývat těmito otázkami a také obecně tím, jak zařídit, aby celý systém dohromady lépe fungoval. Mluvit se bude asi o zavedení kontroly nad API pro uživatelský prostor.

Půlhodinová schůzka je vyhrazena vztahům mezi vývojáři. Komunita vývojářů jádra viditelně roste, což je dobře. Zajištění pokračujícího vývoje jádra vyžaduje přivádění stále nových vývojářů - ze všech konců světa. Schůzka bude místem, kde se bude mluvit o tom, jak toho docílit, a jak zvýšit účast lidí z částí světa, které mají nižší zastoupení.

Andrew Morton dostane hodinu na to, aby si bouchnul do stolu kvůli kvalitě jádra a příbuzným tématům. Mezi vývojáři stále panuje přesvědčení, že v jádru nenarůstá počet chyb, ale ne všichni s takovým pohledem souhlasí. Všichni se však shodují v tom, že méně chyb by bylo ku prospěchu věci. Takže se bude pravděpodobně mluvit o sledování chyb, řešení nedostatku lidí, kteří by kontrolovali kód, případných stabilizačních vydáních atd.

Na programu je samozřejmě i dokumentace - všichni by jí chtěli více, ale ona se, kupodivu, nechce sama od sebe objevit. Minulý rok se mluvilo o zavedení povinné dokumentace pro nové patche, ale málokdo to bral vážně. Takže se možná letos objeví nové nápady, jak situaci zlepšit. Dostane se možná i na překlady jádra a standardizaci jaderných zpráv.

Do pozdního setkání na druhý den bylo zařazeno několik dalších procesních otázek. Stojí za to dělat velké čistky kódu? Jak zdokonalit práci s velkými patchi, které ovlivňují několik různých subsystémů? Jak se vypořádat s problematickými správci? A obecně, je proces vývoje jádra příliš rychlý? Ale možná bude hlavním tématem diskuze návrh Andrew Mortona, aby vývojáři založili odbory a požadovali pořádné zvýšení výplaty.

Pročištění API pro blokové ovladače

Kdysi dávno implementovaly ovladače blokových zařízení stejnou strukturu file_operations, jakou používají znakové ovladače - přestože jsou dost odlišné a mnohé metody ve file_operations se jich vůbec netýkají. Pro verzi 2.4 však bylo API pro blokové ovladače výrazně přepracováno a struct file_operations už se nepoužívala. Místo toho mají blokové ovladače strukturu block_device_operations, která obsahuje mnohé z exportovaných operací ovladače. "Mnohé", protože některé další operace, včetně těch, které dávají I/O požadavky do fronty, jsou místo toho uloženy ve struktuře fronty požadavků.

Když proběhla změna na block_device_operations, bylo několik metod přeneseno přímo z file_operations, aniž by se jejich prototypy změnily. To minimalizovalo nepříjemnosti pro správce ovladačů, ale také vedlo k několika zajímavým pozůstatkům v rozhraní. Například metoda open() vypadá takto:

int (*open)(struct inode *ino, struct file *filp);

Když je otevíráno znakové zařízení nebo soubor, filp ukáže na interní strukturu file, kterou jádro použije ke správě otevřeného souboru. Když otevře blokové zařízení přímo uživatelský proces, použije se filp stejným způsobem. Většinou jsou však bloková zařízení otevírána jádrem jako jeden z kroků k připojení souborových systémů, které tam jsou. V takových případech neexistuje žádná přiřazená struktura file. Proto se v kódu dočtete například tohle:

    /*
     * Tenhle humus je tu kvůli špatné volbě typu ->open().
     * Bude to odstraněno.
     * Prozatím _nesmí_ rutina ->open() u blokového zařízení
     * zkoumat nic v 'inode' kromě ->i_rdev.
     */
    struct file fake_file = {};
    struct dentry fake_dentry = {};
    fake_file.f_mode = mode;
    fake_file.f_flags = flags;
    fake_file.f_path.dentry = &fake_dentry;
    fake_dentry.d_inode = bdev->bd_inode;

Al Viro (který má na svědomí většinu současného API) se tímto a ještě dalšími problémy začal zabývat. V případě open() používají ovladače jen velmi malou část informací, které jsou předávány v inode a file. A něco z toho riskantními způsoby - každý ovladač, který závisí na tom, že cokoliv z fake_file přežije volání open(), bude mít potíže. API má i další neduhy, což Ala vedlo k navržení výrazných změn. Výsledkem, jehož začlenění je téměř jisté, až bude hotov (možná už pro 2.6.24), bude čistší API pro blokové ovladače - za cenu změn pro všechny stávající ovladače.

První změnou bude přesun některých příznaků nacházejících se ve f_flags do f_mode, která nemůže být změněna voláním fcntl() z uživatelského prostoru. V rámci přesunu se bude od ovladačů očekávat, že tyto příznaky - nebo kteroukoliv jinou část struktury file - nezmění. Díky této změně bude možné pročistit trochu kódu v neoblíbeném ovladači floppy, který v současné době do této struktury ukládá informace při open().

Nový prototyp open() by měl vypadat takto:

int (*open)(struct block_device *bdev, mode_t mode);

Kde mode má obvyklé příznaky read/write, ale také některé další příznaky týkající se času, např. O_NDELAY. Hodnotu nebudou měnit ovladače a nemusí nutně existovat v žádné struktuře file. Bude bezpečně uložena na blíže neurčeném místě v jádře a k dispozici bude v okamžiku release(), kdy budou některé ovladače potřebovat k příznakům přístup.

A když už mluvíme o release(), i tato funkce má v současné době starý prototyp:

int (*release)(struct inode *ino, struct file *filp);

V tomto případě je filp jádrem často předávána jako NULL, což ovladače nutí hodnotu kontrolovat a implementovat nějaké výchozí chování, když struktura file neexistuje. Ale někdy ovladače potřebují vědět o některých příznacích, které byly poskytnuty při open(). Takže nová metoda release() bude vypadat takto:

int (*release)(struct gendisk *disk, mode_t mode);

A to není vše. Al poukazuje na to, že rozhraní ioctl() je trochu zmatené:

int (*ioctl)(struct inode *ino, struct file *filp, unsigned cmd, 
                 unsigned long arg);
long (*unlocked_ioctl)(struct file *filp, unsigned cmd, unsigned long arg);
long (*compat_ioctl) (struct file *filp, unsigned cmd, unsigned long arg);

Různé verze mají různé parametry - a dokonce různé návratové typy. Ovladače se opět příliš moc nezajímají o většinu toho, co by mohlo být ve strukturách inode a file - i když ty struktury existují. Takže nová podoba metody ioctl() bude:

int (*ioctl)(struct block_device *bdev, mode_t mode, unsigned int cmd, 
                 unsigned long arg);
int (*compat_ioctl)(struct block_device *bdev, mode_t mode, unsigned int cmd,
                 unsigned long arg);

Všimněte si, že unlocked_ioctl() zmizelo: už je načase se zbavit velkého jaderného zámku [big kernel lock (BKL)] v blokové implementaci ioctl(). Takže všechny ovladače, které pořád používají zamknutou verzi (ioctl() ve starém API), budou změněny, aby braly BKL interně. Nicméně každý ovladač, který stále vyžaduje BKL, by potřeboval pořádnou kontrolu.

Zatím se v souvislosti s navrhovanými změnami neobjevily žádné námitky. Linus k tomu říká:

Podle tvého popisu s tím nemám problém - všechno zní dobře. Starosti mi dělá jen to, jak moc to bude nakonec bolet (a obava, jestli to neovlivní tunu externích modulů... ale na druhou stranu nevidím důvod, proč bychom se kvůli nim měli trápit).

Al říká, že na patchi pracuje, a měl by být brzy představen k posouzení, a že to tak moc bolestivé nebude - alespoň pro ovladače v jádře. Pro ty, kdo spravují blokové ovladače mimo jádro, je varování jasné - blíží se významná změna API.

Další pokus o odstranění sysctl()

Systémové volání sysctl() umožňuje aplikaci s odpovídajícími právy upravovat jisté parametry jádra. Je to užitečná funkce, která však není skoro vůbec využívána. Důvodem je existence virtuální adresářové hierarchie /proc/sys, jež exportuje stejnou funkčnost v podobě, kterou je mnohem snazší používat. Uživatelům sysctl() bylo dlouho doporučováno, aby raději používali /proc/sys, a přidávání nových parametrů do sysctl() je považováno za porušování pravidel. Před rokem bylo sysctl() odstraněno z jádra 2.6.19-rc, ale ještě před finální verzí bylo vráceno.

sysctl() je součástí uživatelského ABI; mělo by fungovat už navždy. Proto byl pokus o odstranění nakonec vrácen. Takže je možná překvapivé, že se objevil nový pokus od Erica Biedermana. Jeho poslední patch přidává varování o zastaralosti [deprecated] a záznam do plánu pro odstraňování funkcí, který určuje konec sysctl() na září 2010. Eric vysvětluje:

Po přidání kontroly do register_sysctl_table a objevení celé nové skupiny chyb, která zůstala nepovšimnuta při nespočtu kontrol kódu a testerů, jsem konečně ztratil s binárním rozhraním sysctl trpělivost.

Binární rozhraní sysctl je v podstatě zastaralé už roky a snaha o nalezení uživatelského programu, který by ho používal, je marnější než hledání jehly v kupce sena. A u implementace v jádře se objevují další a další problémy. A protože podporovat něco, co nikdo nepoužívá, je praštěné, nechte systcl zastarat s dostatečnou lhůtou, aby bylo možné tu hrstku aplikací, kterým na tom záleží, opravit nebo nahradit.

Eric tvrdí, že je rozhraní tak málo používáno, že zjevně zahnívá. Implementace sysctl() a /proc/sys jsou dost odlišné na to, aby se od sebe snadno odchýlily. Z dlouhodobého hlediska bude pro jadernou komunitu snazší nezpůsobit aplikacím problémy, když odstraní sysctl() ve prospěch rozhraní, které je skutečně používáno a spravováno.

Nový patch vyvolal dle očekávání protesty vývojářů, kteří nechtějí takovým způsobem narušit uživatelské ABI. Alan Cox také podotkl, že varování o zastaralosti nepřiměje těch několik zbývajících uživatelů, aby přešli na /proc/sys:

Celý tenhle postup s trochou fňukání nefunguje, když se snažíš přesvědčit lidi, pro které to není koníček. Nechtějí nic měnit, pro ně je ta zpráva jen nepříjemnost a jejich upstreamový dodavatel obrovského softwarového balíku nebude něco měnit, jen aby se s tím vypořádal. Označí to tedy jako chybu a budou tak dlouho posílat bugreporty, dokud to nepřestane.

Andrew Morton se tomu naopak nebrání:

Myslím, že to stojí za pokus. Možná to bude trvat dva, tři nebo pět let, kdo ví? Když se ukáže, že to není praktické, můžeme si to vždycky rozmyslet. Žádná velká ztráta.

Ačkoliv téměř všichni souhlasí s pravidlem, že by se uživatelské ABI nemělo narušovat, vypadá to, že je prostor k diskuzi o tom, jak tohoto cíle co nejlépe dosáhnout. Nevyužívaný kód měl vždycky sklony k náhodným problémům a sysctl() vypadá velmi blízko stavu, kdy nebude používáno vůbec. Možná by se to dalo řešit nějakým balíkem testů na regrese - což by se jádru obecně hodilo. Správa rozhraní, o které je zájem pouze z historického hlediska, však není pro uživatele Linuxu ničím přínosná. Takže by měl asi existovat způsob, jak odstranit systémová volání, která jsou dlouhou dobu nepoužívána. Pokud tento patch projde, uvidíme, jestli na takovou změnu stačí tři roky.

       

Komentáře

[Filip Jirsák]

• jiný mi slovy – mezera navíc
• předběžný program již byl vystaven – velké P na začátku věty
• správě paměti nebo ovladačích zařízení se vždy budou týkat je malé skupiny – jen malé skupiny, chybí "n"

[Robert Krátký]

To je úrodička . Dík, opraveno.

[MiHl]

Prdící růžová lasička?
první věc po ránu, co mě pobavila a to bych to v této kategorii ani nečekal... někdo má asi hodně fantasie :D

[Pavel Půlpán]

LOL

[stativ]

Oni svatí tancující kapustňáci u současného jádra jsou taky dobří, že ano Batmane?

[Láďa]

Podle mě se trochu trefují do způsobu pojmenování verzí v Ubuntu

[Martin Doucha]

Článek, ze kterého je citát týdne, také stojí za to

[zelial]

to je perla! windows media player jako traffic shaper v (uz tak mizerne) implementaci sitove vrstvy ve viste.

reknete wow.

[F]

hmm nevim proc je sitova vrstva ve Viste mizerna, zdrojaky jsem nevidel... Jinak ten problem co popisujou v tom clanku neni presny, nektere sitovky nemely problem s DPC z ISR ale z periodickyho timeru. Kdyz jsem psal real time rozsireni jadra tak jsem DPC od sitovky presunul do worker threadu (ano, kernel je preemptivne planovan).

[zelial]

to byla narazka na 41% zatizeni procesoru pri obycejnem kopirovani souboru po siti, ktere ukazuje mark russinovich v blogu o tomhle problemu.

[F]

Bohuzel krome cisla 41 tam neni nic blizsiho(?). Ja mam zkusenost takovou, ze vetsinou je zpraseny driver k sitovce od treti strany. To ze ale rutiny volane z NdisMSetPeriodicTimer bezi v DPC levelu (a blokuji vsechny thready) je opravdu problem MS.