Portál AbcLinuxu, 20. května 2024 02:27
Aktuální verze jádra: 2.6.26-rc1. Citáty týdne: Andrew Morton, Rusty Russel, Willy Tarreau. Poslední záležitosti, které prošly začleňovacím oknem 2.6.26. Je na čase zpomalit vývoj jádra? Vázané připojení pouze ke čtení.
Současná předverze jádra 2.6 je 2.6.26-rc1 vydaná 3. května. Tak tohle začleňovací okno bylo poněkud drsné ve smyslu, že se o něm vedlo hodně hádek, ale já osobně si zároveň myslím, že z technického úhlu pohledu bylo v poslední době pravidlem, že se děly méně děsivé věci. Při přibližně 7500 commitech obsahuje tento cyklus méně změn, než mělo těch pár předtím; spousta změn je v infrastruktuře, takže viditelných nových vlastností bude v 2.6.26 méně než v jeho předchůdcích. Detaily vizte ve zkráceném changelogu, spoustu detailů v kompletním changelogu.
Do hlavního repozitáře po vydání -rc1 proudil relativně pomalý proud patchů.
Současná verze stabilního jádra je 2.6.25.2 vydaná 6. května. Toto vydání obsahuje jedinou opravu pro lokálně zneužitelný bezpečnostní problém v kódu zámků souborového systému. Tato oprava byla vydána také v 2.6.24.7 a 2.4.36.4.
Větší skupina oprav byla vydána v 2.6.25.1 a 2.6.24.6. Pokud se neobjeví nějaké bezpečnostní záležitosti, pravděpodobně nebudou žádné další aktualizace stabilního 2.6.24.
Obvykle vězí základ mých problémů s gitem v tom, že nemám PhD v hermeneutické metafyziologii, ale tentokrát ne. Si myslím.
Děti: nestrkejte do svého jádra náhodné jaderné moduly. Jenom protože něco dělá Linus, to ještě nemusí být dobrý nápad...
Polovinu jaderné inteligence jsme přesunuli do uživatelského prostoru v udev, initrd a modulech; je skutečně nefér, že s námi nesdílíte ten skvělý proč-můj-stroj-nebootuje pocit.
-- Rusty Russel
Jaderný tým se vyvinul z malého týmu kámošů do velkého podniku. A abychom přežili tuto evoluci, možná budeme muset použít některé z těch nemorálních principů, které jsou k vidění u velkých firem.
Po zveřejnění prvního a druhého shrnutí začleňovacího okna 2.6.26 bylo začleněno okolo 500 sad změn. Začleňovací okno bylo uzavřeno; zde je poslední sada změn, které se dostaly dovnitř:
Nové ovladače pro
Na architektuře x86 jsou opět výchozí 8kB zásobníky. Situace, kdy dojde paměť, jsou méně problematické, než tiché a těžce laditelné poškození zásobníku.
Typ klist (kseznam) má nyní pro deklaraci a inicializaci makra v obvyklé formě: DEFINE_KLIST() a KLIST_INIT. Dvě nové funkce (klist_add_after() a klist_add_before()) mohou do klistu přidávat záznamy na specifikovanou pozici.
struct class_device byla podle plánu odstraněna z jádra ovladačů společně s ní spojenou infrastrukturou. Třídy jsou nyní implementovány pomocí běžné struct device.
kmap_atomic_to_page() již není exportována modulům.
Jsou k dispozici nové obecné funkce pro provádění 64bitového celočíselného dělení v jádře:
u64 div_u64(u64 dividend, u32 divisor); u64 div_u64_rem(u64 dividend, u32 divisor, u32 *remainder); s64 div_s64(s64 dividend, s32 divisor) s64 div_s64_rem(s64 dividend, s32 divisor, s32 *remainder);
Narozdíl od do_div() je u těchto funkcí explicitně udáno, jestli se jedná o znaménkovou nebo bezznaménkovou matematiku. Pro x86 specifická funkce div_long_long_rem() byla odstraněna ve prospěch těchto nových funkcí.
Je zde nová řetězcová funkce:
bool sysfs_streq(const char *s1, const char *s2);
Porovnává dva řetězce a ignoruje přitom volitelný znak konce řádky.
Prototyp pro i2c metody probe() se změnil:
int (*probe)(struct i2c_client *client,
const struct i2c_device_id *id);
Nový argument id podporuje aliasing jmen i2c zařízení.
Byla zavedena nová konfigurační volba (MODULE_FORCE_LOAD), která určuje, jestli je možné násilím nahrát modul, i když si jádro myslí, že to není správně; výchozí hodnota je "ne."
Všechny komunity si postupem času vybudují rituály. Jedním z přetrvávajících rituálů na linux-kernel je pravidelná vášnivá diskuze na téma vývojový proces a kvalita jádra. Pro vnějšího pozorovatele tyto události mohou budit dojem, že celý ten podnik se musí rozpadnout. Nicméně skutečnost je dost podobná oslavě nového roku, u níž měl autor článku příležitost být v Pekingu: spousta hluku a kouře, ale druhý den se všichni vrátí do práce.
Nicméně i v diskuzích tohoto typu se skrývá nějaká skutečná hodnota. Jakákoliv skupina, která se zabývá věcmi, jako je kvalita, musí občas udělat krok zpět a vyhodnotit situaci. I když z toho nejsou žádné okamžité výsledky, nápady, které se objeví, se často vrací během několika následujících měsíců a vedou ke skutečnému zlepšení.
Inspirací pro toto kolo diskuze byly nefungující systémy jako výsledek začleňovacího okna 2.6.26. Tento vývojový cyklus měl drsnější start než jiné, větší než obvyklé množství patchů způsobilo selhání při bootu a další nevhodné chování. To vedlo mezi vývojáři k nějakým tahanicím o to, jak by mělo být nakládáno s patchi. Vadné patche jsou nepříjemné, ale stojí za to poznamenat jednu věc: tyto problémy byly podchyceny a opraveny ještě předtím, než bylo vydáno 2.6.26-rc1. Problémy, které nastartovaly tohle kolo diskuze, nejsou chyby, které by postihly uživatele Linuxu.
Nadevší pochybnost ale budou jiné chyby, které se vynoří pomaleji a budou pomaleji opraveny. Počet těchto chyb vedl k mnoha voláním po tom, aby byl vývojový proces nějakým způsobem zpomalen. V tomto ohledu se hodí si všimnout, že proces se zpomalil, začleňovací okno 2.6.26 přineslo mnohem méně sad změn, než bylo k vidění v 2.6.24 či 2.6.25. Jestli bude toto pomalejší tempo pokračovat i v budoucích cyklech, nebo to byla prostě přestávka po dvou obzvláště rušných vývojových cyklech, to se ještě uvidí.
Jenže jestli se proces nezpomalí sám, jsou zde vývojáři, kteří by chtěli nalézt způsob, jak ho k tomu přinutit. Někteří argumentovali pro prosté přiškrcení [throttling] procesu tak, že by například omezili počet nových vlastností v každém vývojovém cyklu pro jednotlivé subsystémy jádra. Také kolovaly řeči o vybrání subsystémů s nejhorším počtem regresí a nezačleňování nových vlastností do doby, než se věci zlepší. Faktem ovšem je, že omezování situaci pravděpodobně nepomůže.
Zpomalení začleňování totiž vývojářům nezabrání vyvíjet, akorát to udrží jejich kód mimo strom. Extrémní příklad lze najít v jádře 2.4: začleňování nového kódu bylo dlouho značně omezováno, až nakonec došlo k tomu, že distributoři začali začleňovat nový vývoj sami, protože jejich uživatelé to požadovali. Takže spousta jader, které se jmenovaly "2.4", se podstatně lišila od čehokoliv, co se dalo stáhnout z kernel.org. Na této cestě čeká fragmentace a téměř s určitostí také nižší kvalita.
Linus ve skutečnosti tento argument vzal a použil ho k tvrzení, že rychlé začleňování patchů vede k lepší kvalitě:
Osobně věřím, že nejlepší způsob, jak zlepšit kvalitu kódu, je distribuovat ho. Ano - pro účely této diskuze - jako patche, ale ještě více jako část soudržného celku - jako začleněné patche!
Vtip je v tom, že na kvalitě jednotlivých patchů nezáleží! Záleží na kvalitě celkového výsledku. A lidé budou mnohem více zatahováni do toho, aby se dívali, testovali a pracovali s kódem, který je začleňován, než s kódem, který není.
Proti omezování argumentoval i Andrew Morton:
Jestliže věci jednoduše omezíme, lidé stráví víc času sledováním teleshoppingů, ale budou začleňovat menší množství úplně stejného svinstva.
Jaderní vývojáři jsou samozřejmě známí jako notoričtí nakupovači, takže dávat jim více příležitosti provozovat tuto aktivitu pravděpodobně není nejlepší nápad. No, ale vážně: Andrew je pro zpomalení vývojového procesu, ale jenom pokud se k tomu přistoupí z jiného úhlu - jeho názorem je, že zvýšené zaměření se na kvalitu bude mít jako vedlejší efekt zpomalení vývoje. Je potřeba, aby se jaderní vývojáři zaměřili na hledání a opravu chyb místo na vytváření nových a/nebo nakupování.
Je vhodné poznamenat, že významná část komunity vývojářů věří tomu, že v tomto ohledu nejsou žádné problémy. Chyby jsou nacházeny a opravovány rychlým tempem a pro většinu uživatelů je jádro solidní. Arjan van de Ven psal:
Opravdu se ohledně kvality zhoršujeme? Můj (subjektivní) dojem je, že jsme na tom lépe než minulý rok. Na kvalitu jsme zaměření více. Opravujeme chyby, které lidem vadí nejvíc. Opravujeme většinu regresí (uznávám, ne všechny). V subsystémech vidíme plochou nebo klesající křivku počtu/poměru chyb.
Ted Ts'o upozornil na to, že mnoho problémů pochází z obskurního a nekvalitního hardwaru a že není možné uspokojit každého. Andrew není přesvědčen a zdá se, že má obavy, že kvalita jádra upadá.
V jistém smyslu je tato část diskuze pouze akademická. Nikdo by se nehádal o tom, že méně chyb není dobrý cíl, bez ohledu na to, jestli věří, že současný vývojový proces má problémy s kvalitou. Debata o způsobech, jak věci vylepšit, je tedy vždy k tématu.
Testování je stále velký problém; jádro je mnohem citlivější na to, na jakém systému běží, než většina jiných projektů. Mnoho problémů (možná většina z nich) je spojená s nějakým specifickým hardwarem nebo specifickou kombinací hardwaru; není možné, aby vývojáři, kteří nemají všechen existující hardware, mohli najít všechny chyby. Uživatelé musí v tomto procesu pomoci. Dosažení široce rozšířeného pokrytí testováním je vždy těžké; Peter Anvin tvrdí, že současný proces to ještě ztížil:
Jeden problém je, že stále fragmentujeme základnu testerů přidáváním nových úrovní sebedůvěry: nyní máme -mm, -next, -git hlavní řady, -rc hlavní řady, vydání hlavní řady, stabilní, testovací u dister a vydání u dister (a některá distra mají ještě agresivní versus konzervativní větve). Navíc kvůli kraniorektálnímu vnoření na straně výrobců grafického hardwaru musí spousta uživatelů na svých "hlavních pracovních" systémech používat proprietární ovladače, což znamená, že nová vydání nemohou testovat, ani kdyby chtěli.
Ve skutečnosti je nepřeberné množství jader, která je možné testovat, a není vždy zcela jasné, kde by uživatelé a vývojáři měli koncentrovat své snahy. Nicméně se formuje konsenzus, že by se mělo víc lidí dívat konkrétně na strom linux-next. Linux-next je místo, kde by se měly shromáždit všechny patche zamýšlené pro další začleňovací okno; současný obsah linux-next je v době psaní tohoto článku zaměřen na 2.6.27. To je místo, kde mohou být nalezeny časné problémy s integrací a jiné; jestliže bude linux-next dobře otestován, počet problémů, které se objeví v dalším začleňovacím okně, by se měl o něco zmenšit.
Strom linux-next je zajímavý experiment. Prakticky prodlužuje vývojový cyklus: od té doby, co existuje linux-next, v podstatě začal vývojový cyklus 2.6.27. Linux-next také dělá něco, čemu jaderní vývojáři měli tendence odporovat: způsobuje, že stabilizační období jednoho vývojového cyklu se překrývá s aktivním vývojem dalšího cyklu. V minulosti se vedly dohady o tom, že toto překrytí povede vývojáře k tomu, aby se více zaměřili na vytváření nových hraček než na opravování problémů v hračkách z minulého týdne.
Někteří lidé tvrdí, že to se děje už teď: vývojáři netráví dost času vypořádáváním se s chybami - a na prvním místě je to jejich neopatrnost, co vytváří příliš mnoho chyb. Jiní tvrdí, že i když nebude možné opravit všechny ohlášené chyby, chybám, na kterých opravdu záleží, se někdo věnuje. Skutečné rozřešení této neshody se nezdá pravděpodobné; vytvoření smysluplného systému, který by měřil kvalitu jádra, je obtížný úkol. To nejlepší, co se dá dělat, je snažit se udržet seznam regresí tak malý, jak to jen jde; dokud systémy, které dříve fungovaly, fungují dál, je těžké hádat se příliš hlasitě o tom, že věci směřují špatným směrem.
Vázaná připojení [bind mounts] lze považovat za druh symbolického odkazu na úrovni souborového systému. Použitím mount --bind je možné vytvořit druhý přípojný bod existujícího souborového systému a vidět ho tak z jiného místa ve jmenném prostoru. Vázaná připojení jsou tedy užitečná pro vytváření specifických pohledů na jmenný prostor souborového systému; například jimi lze vytvořit takové připojení, které zviditelní část souborového systému v prostředí, které je jinak uzavřeno do chroot().
V jádrech do verze 2.6.25 je nicméně v implementaci vázaných připojení jedno omezení: platí pro ně stejné připojovací volby jako pro primární připojení. Takže příkazu jako je:
mount --bind -o ro /dulezita_data /neduveryhodny_kontejner/dulezita_data
se v /neduveryhodny_kontejner nepodaří připojit /dulezita_data pouze pro čtení, pokud byla původně připojena i pro zápis. Na systému autora článku je toto selhání tiché - vázané připojení je zapisovatelné, přestože bylo požadováno pouze pro čtení, a nevygeneruje se žádné chybové hlášení (v manuálové stránce k mount se píše, že volby nelze změnit).
Schopnost zajistit, aby byla vázaná připojení pouze pro čtení, má zjevně svoji hodnotu. Kontejnery jsou jeden příklad: správce si může přát vytvořit kontejner, ve kterém mohou běžet procesy pod rootem. Může být užitečné, aby měl kontejner přístup k souborovému systému hostitele, ale nemusí mít nutně právo do tohoto souborového systému zapisovat. Od 2.6.26 bude toto nastavení možné díky začlenění patche vázaných připojení pouze pro čtení od Dave Hansena.
Nicméně, stále není možné vytvořit vázané připojení pouze pro čtení příkazem uvedeným výše; atribut pouze pro čtení lze přidat jen znovupřipojovací [remount] operací o něco později. Potřebná sekvence příkazů je tedy takováto:
mount --bind /vital_data /untrusted_container/vital_data mount -o remount,ro /untrusted_container/vital_data
Tento příklad nastoluje zajímavou otázku: co když nějaký proces otevře soubor pro zápis mezi těmito dvěma mount operacemi? Správce systému má právo očekávat, že připojení pouze pro čtení bude skutečně používáno pouze ke čtení. Patch do 2.6.26 je navržen tak, aby toto očekávání dodržel, i když se ukázalo, že množství k tomu potřebné práce bylo větší, než vývojáři očekávali.
Souborové systémy obvykle sledují, které soubory jsou otevřené pro zápis, aby pokus znovupřipojit souborový systém pouze ke čtení mohl být předán nízkoúrovňovému kódu souborového systému ke schválení. Nízkoúrovňový souborový systém ale neví nic o vázaných připojeních, ta jsou zcela implementována ve vrstvě virtuálního souborového systému (VFS). Takže zajistit přístup pouze pro čtení pro vázaná připojení vyžaduje, aby VFS sledoval všechny soubory, které byly otevřeny pro zápis. Nebo přesněji, VFS ve skutečnosti potřebuje sledovat pouze to, kolik souborů je otevřeno pro zápis.
Technika, která se k tomu používá, využívá něco, co vypadá jako zápisový zámek pro souborové systémy. Kdykoliv chce VFS provést nějakou akci, která zahrnuje zápis, musí nejdřív zavolat:
int mnt_want_write(struct vfsmount *mnt);
Návratová hodnota je nula, pokud je možný zápis, nebo záporný chybový kód v opačném případě. Toto volání lze nalézt na zjevných místech - jako například v implementaci open() - kde je požadován přístup s možností zápisu. Nicméně přístup k zápisu se dostává do hry v mnoha dalších situacích; například přejmenování souboru vyžaduje přístup k zápisu během trvání operace. Proto byla volání mnt_want_write() rozsypána do celého VFS kódu.
Když již není přístup k zápisu potřeba, "zápisový zámek" by měl být uvolněn voláním:
void mnt_drop_write(struct vfsmount *mnt);
Jedním z objevů bylo, že přístup k zápisu je potřeba na více místech, než by si kdo myslel. Konkrétně se ukázalo, že je potřeba volat mnt_want_write() i v nízkoúrovňovém souborovém systému, stejně jako ve VFS vrstvě. Proto formování patche znamenalo dlouhodobý proces hledání míst, která byla přehlédnuta, a přidávání mnt_want_write(). Ve snaze snížit náchylnost tohoto procesu k chybě dal Miklos Szeredi dohromady sadu pomocných funkcí ve VFS, které obalují situace, ve kterých je potřeba přístup k zápisu. Tyto funkce nicméně do 2.6.26 začleněny nebyly.
mnt_want_write() je pochopitelná na první pohled - jednoduše inkrementuje počítadlo probíhajících přístupů k zápisu. Problém byl v jednoduché implementaci, protože sdílený čítač za každý souborový systém by způsobil problémy se škálovatelností. Na multiprocesorových systémech by řádka v cache obsahující čítač poskakovala systémem a věci by se výrazně zpomalily.
Běžnou reakcí na tento druh problému je změnit čítač na proměnnou pro každý procesor [per-CPU], čímž se umožní, aby operace s čítačem zůstaly pro daný procesor lokální. Když někdo potřebuje znát celkovou hodnotu čítačů, jednoduše sečte verzi od každého CPU; tato operace je pomalá, ale také nepříliš častá. Na velkých systémech ale počet CPU může být velký - stejně jako počet souborových systémů a vázaná připojení tento počet ještě zvýší. Výsledkem je násobící efekt, který - opět - představuje problém se škálovatelností, akorát se v tomto případě projeví jako velká spotřeba paměti.
Patch vázaných připojení pouze ke čtení řeší tuto situaci tak, že se vrací ke globálním čítačům, které jsou cachovány na specifických procesorech. Každé CPU má za tímto účelem jednu z těchto struktur:
struct mnt_writer {
spinlock_t lock;
unsigned long count;
struct vfsmount *mnt;
}
Tato struktura neustále udržuje lokální součet pro jeden souborový systém reprezentovaný mnt. Jestliže procesor potřebuje přizpůsobit počet souborů otevřených pro zápis v daném souborovém systému, jde o jednoduchou záležitost inkrementace nebo dekrementace count. Když se pozornost procesoru obrátí k jinému souborovému systému, musí nejdřív přizpůsobit globální součet starého souborového systému, potom může teprve přepnout své mnt_writer na nový. Výsledek je kompromisem mezi zcela lokálními a zcela globálními čítači a poskytuje "dostatečně dobrý" výkon na benchmarcích vytvořených k zatížení systému.
Vázaná připojení pouze ke čtení se připojují k ostatním vlastnostem (jako jsou sdílené podstromy) a vytváří tak flexibilní sadu nástrojů pro vybudování jmenného prostoru souborového systému. Není jasné, kolik z těchto funkcí je v současnosti využíváno, ale jak se implementace kontejnerů v hlavní řadě blíží dokončení, o tuto schopnost bude pravděpodobně víc zájmu. Linuxové systémy mohou mít v následujících letech komplexnější strukturu souborového systému v porovnání s tím, co bylo k vidění v minulosti.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.