Portál AbcLinuxu, 6. května 2025 00:06
Aktuální verze jádra: 2.6.27-rc3. Citáty týdne: Alan Cox, Eric Paris. Příručka pro přispívání k linuxovému jádru vydaná Linux Foundation. Vydání Revize operačních systémů ACM o linuxovém jádře je k dispozici. Jaderné kontrolní body a restart. Vyřazovací požadavky pro blokovou vrstvu. Udev pravidla a správa instalatérské vrstvy.
Současné vývojové jádro je 2.6.27-rc3 vydané 12. srpna. Společně s očekávatelnou hromádkou oprav toto vydání zahrnuje práci na potlačování velkého jaderného zámku v subsystému watchdogu, i2c ovladač SMSC SCH5027, ovladač pro čip pro sledování teploty Analog Devices AD7414 a nový ovladač ath9k (pro zařízení Atheros 802.11n), kterým přispěl Atheros. Detaily najdete ve zkráceném changelogu, spoustu detailů v kompletním changelogu.
V době psaní tohoto článku nebyly od vydání 2.6.27-rc3 do repozitáře hlavní řady začleněny žádné změny.
Během minulého týdne nebyly vydány žádné aktualizace stabilního jádra.
Nyní je zabezpečení počítačů trochu odlišné, protože má vlastnosti noci oživlých mrtvých, kde se zombie nejenom mohou protáhnout skrz okno na záchodě, ale také umí změnit stráže na zombie, nicméně základní předpoklad je v podstatě stejný.
-- Alan Cox
Takže asi po týdnu snahy vymáčknout informace z protimalwarových firem mám pocit, že mohu lépe hovořit za jejich potřeby (ačkoliv asi nebudou mít radost z toho, co chci říci). Rád bych upozornil na to, že mnoho podniků bude tuhle věc na svých strojích provozovat. Tečka. Konec příběhu. Osobně bych raději podporoval čisté rozhraní místo toho, abych se musel snažit dělat technickou podporu zákazníkům, když mají jejich křehké hacknuté systémy problémy.
-- Eric Paris ukazuje model ohrožení [threat model] pro TALPA
Linux Foundation vydala tiskové prohlášení, ve kterém oznamuje dostupnost Jak se zapojit do linuxové komunity, rozšířené příručky sepsané redaktorem LWN Jonathanem Corbetem. 'Linux Foundation slyší od vývojářů z celého světa, že se chtějí zapojit do jaderné komunity, ale někdy mají problém s tím, že neví jak,' řekla Amanda McPherson, víceprezidentka, marketingové a vývojářské programy. 'Tato nová příručka ten proces zjednoduší a přivede do náruče Linuxu nové firmy a vývojáře.'
Společnost pro výpočetní stroje [Association for Computing Machinery, ACM] vydala Přehled operačních systémů [Operating Systems Review] s tématy, které se týkají linuxového jádra. Vydání obsahuje příspěvky o různých tématech zajímavých pro jaderné hackery a ty, kteří jádro jen sledují. Zahrnuje 12 příspěvků o pokrocích, které byly začleněny nebo jsou kandidáty na začlenění do linuxového jádra, stejně jako nové příspěvky diskutující slibnou experimentální práci. Více informací a obsah najdete pod odkazem níže.
Jonathan Corbet, autor tohoto článku, který před svým čtenářstvem pečlivě skrýval několik let zkušeností s vědeckým programováním založeným na Fortranu, narazil na techniku kontrolního bodu [checkpoint] a restartu před dlouhou dobou. V těch dnech programy, které měly běžet několik dní na těžce vydobytém času CPU na nepředstavitelně rychlých CDC nebo Cray mainframech, občas vytvořily kontrolní bod sama sebe, čímž se minimalizoval ztracený výpočetní čas, když (nikoliv jestliže) systém spadl v nevhodný čas. Byl to určitý druh pojištění, pojistné bylo vypláceno ve formě pravidelných volání kontrolních bodů.
Čas hlavního procesoru již není tak nedostatkový, nicméně je stále zájem mít k dispozici schopnost vytvořit kontrolní bod běžící aplikace a obnovit její stav někdy v budoucnosti. Jednou možnou aplikací této schopnosti je obnovit program na jiném stroji; tímto způsobem je možné přesunout běžící program z jednoho hostitele na jiný. A jestliže je "program" celý kontejner plný úloh, nabízí se možnost přesouvat tyto kontejnery, aniž by si programy v nich byly vědomy toho, že se to děje. To může obratem poskytnout možnost vyvažování výkonu nebo odstranit kontejner ze stroje, který se vypíná.
Linux tuto schopnost nyní nemá. Každý, kdo přemýšlí o jejím přidání, musí své vyhlídky považovat za skličující; programy mají spoustu stavových informací uložených po celém systému. Stav zahrnuje otevřené soubory (a pozice v nich), síťové sockety a roury propojené se vzdálenými protějšky, stavy signálů, běžící časovače, popisovače speciálních souborů (například pro epoll_wait()), stav ptrace(), příklon [affinity] k CPU, SYSV semafory, futexy, stav SELinuxu a mnoho dalších. Selhání při ukládání a správného obnovení celého stavu vyústí v poškození procesu. Není divu, že Linux neumí kontrolní bod a restart; většinu rozumných vývojářů odradí komplexita potřebná k tomu, aby to fungovalo alespoň trochu robustním způsobem.
Na druhou stranu byly doby, kdy by se rozumní programátoři ani nepokusili vytvořit Linux - nemělo by tedy být překvapení, že vývojáři pracují i na problému kontrolních bodů a restartu. Nejnovější pokus je k nalezení v této sadě patchů zaslané Davem Hansenem (ale původně napsané Orenem Laadanem). Patche mají daleko od připravenosti k nasazení naostro, ale ukazují přístup, který se používá.
Po nějaký čas převažoval názor, že mechanismus pro kontrolní bod a restart by měl být co nejvíce vytlačen do uživatelského prostoru. Proces by měl zařídit sesbírání svého stavu a zapsat ho do souboru; jádro by bylo zahrnuto, jenom pokud by to bylo nezbytně nutné. Ukazuje se ale, že nezbytně nutné zahrnutí nastává poměrně často, což vyžaduje přidání "spousty nových malých jaderných rozhraní", aby všechno fungovalo. Na setkání při OLS se tedy vývojáři rozhodli použít jiný přístup a přesunout práci do jádra. Výsledkem je vytvoření jenom dvou nových systémových volání:
int checkpoint(pid_t pid, int fd, unsigned long flags); int restart(int crid, int fd, unsigned long flags);
Volání checkpoint() zapíše obraz současného procesu do daného fd. Argument pid identifikuje init proces pro kontejner současného procesu; do obrazu je uložen, ale současný patch ho jinak nevyužívá. Jestliže operace uspěje, návratová hodnota bude unikátní (dokud systém nerebootuje) "identifikátor obrazu kontrolního bodu". restart() proces obrátí; crid je identifikátor obrazu, který se v současnosti nepoužívá. Stejně tak se v současnosti nepoužívá ani v jednom volání argument flags. Rozhraní se pravděpodobně změní; jeho další vylepšení bude asi zahrnovat schopnosti jako vytváření kontrolních bodů ostatních procesů a skupin procesů.
Pro checkpoint() i restart() je nyní potřebná kvalifikace [capability] CAP_SYS_ADMIN. To je poněkud nešťastné, protože by bylo hezké, kdyby běžné neprivilegované procesy byly schopny vytvořit kontrolní bod a restartovat samy sebe. Je ale několik bezpečnostních důsledků, které je potřeba mít na paměti, obzvláště když se zváží škody, které by mohly vzniknout při pokusu restartovat pečlivě zmanipulovaný obraz kontrolního bodu. Zabezpečit restart() pro neprivilegované použití nebude práce pro lidi se slabým srdcem.
V tomto stádiu vývoje se patch ani nesnaží řešit celý problém. Je schopen uložit současný stav virtuální paměti (ale pouze v nepřítomnosti neprivátních, sdílených mapování), současný stav procesoru a obsah struktury úloh. To je dost na to vytvořit kontrolní bod a restartovat program "hello, world", ale ne o moc víc. I tak jde ale o rozumné místo, kde začít. Vzhledem ke komplexitě problému je správnou cestou, jak pokračovat, chůze opatrnými dětskými krůčky. V blízké budoucnosti tedy v jádře fungující kontrolní body mít nebudeme, ale se štěstím a trpělivostí se nakonec dostaneme k něčemu, co funguje.
Disky bez pohyblivých částí a úložná zařízení založená na technologii flash se zvětšují a zlevňují do té míry, že na vzrůstajícím počtu systémů začínají nahrazovat rotující disky. I když flash vyžaduje méně energie, méně hlučí a je rychlejší (přinejmenším při náhodném čtení), má samo o sobě nějaké vady. Jednou z nich je potřeba vyvažování opotřebení - snaha udržet počet cyklů výmaz/zápis na každém bloku přibližně stejný, aby se zařízení neopotřebovalo příliš brzy.
Vyvažování opotřebení vynucuje vytvoření zprostředkující vrstvy mapující čísla logických bloků (jak je vidí počítač) na fyzické bloky na médiu. Někdy se o mapování stará překladová vrstva přímo v zařízení; také to může být prováděno v jádře (například v UBI vrstvě), jestliže má přímý přístup na flash pole. Tak jako tak toto mapování přichází do hry pokaždé, když se na zařízení zapisuje blok; když se to stane, vybere se nový blok ze seznamu volných bloků a data se tam zapíší. Blok, který předtím obsahoval data, se přidá na seznam volných.
Když se zařízení zaplní daty, seznam volných bloků se může poměrně zkrátit, což ztěžuje řešení zápisů a narušuje algoritmus vyrovnávání opotřebení. Problém se dále slučuje s faktem, že nízkoúrovňové zařízení ve skutečnosti neví, které bloky obsahují užitečná data. Možná, že jste ráno ze schránky vymazali několik set spamů, ale flash mapovací vrstva nemá žádný způsob, jak to zjistit, takže tato data obezřetně zachovává a přitom křičí po volných blocích, aby bylo kam dát dnešní poštu. Bylo by hezké, kdyby vrstva souborového systému, která ví, že obsah souborů již není potřeba, mohla tuto informaci předat ukládací vrstvě.
Na nižší úrovni vytvořily skupiny, jako je Výbor T13 (který spravuje ATA standardy), rozšíření protokolu, která umožňují hostitelskému počítači sdělit, že určité sektory se již nepoužívají; T13 nazývá nový příkaz "trim". Po přijetí příkazu trim může ATA zařízení okamžitě přidat dané sektory na seznam volných a vyřadit data v nich uložená. Souborové systémy mohou obratem vyvolat vyslání tohoto příkazu pokaždé, když je soubor smazán (nebo zkrácen). To umožní úložnému zařízení plně využívat prostor, který je opravdu volný, takže bude celek fungovat lépe.
Co ale Linux nyní postrádá, je schopnost souborového systému říci nízkoúrovňovému ovladači blokové vrstvy o nepotřebných sektorech. David Woodhouse zaslal návrh, jak tuto mezeru zaplnit, ve formě sady patchů vyřazovacích požadavků. Jak by se dalo očekávat, patche jsou relativně jednoduché - není potřeba přenášet mnoho informací - zbývá ale několik detailů.
V blokové vrstvě je nyní nová funkce pro požadavky, kterou může souborový systém zavolat:
int blkdev_issue_discard(struct block_device *bdev, sector_t sector,
unsigned nr_sects, bio_end_io_t end_io);
Toto volání zařadí do fronty požadavek pro bdev, přičemž říká, že nr_sects sektorů začínajících na daném sector již není zapotřebí a může být vyřazeno. Jestliže nízkoúrovňový blokový ovladač není schopen splnit požadavky na vyřazení, je vráceno -EOPNOTSUPP. V opačném případě požadavek přejde do fronty a když se požadavek na vyřazení dokončí, zavolá se funkce end_io(). Po většinu času se ale souborový systém nebude o dokončení starat - přece jenom pouze předává požadavek ovladači - end_io() tedy může být NULL a stejně se stane správná věc.
Na úrovni ovladačů musí být poskytnuty nové funkce pro nastavení vyřazovacích požadavků:
typedef int (prepare_discard_fn) (struct request_queue *queue,
struct request *req);
void blk_queue_set_discard(struct request_queue *queue,
prepare_discard_fn *dfn);
Aby mohl podporovat požadavky na vyřazení, měl by ovladač registrovat svou funkci prepare_discard_fn() použitím blk_queue_set_discard(). Tato funkce bude obratem volána pokaždé, když je do fronty zařazen požadavek na vyřazení; funkce by měla provést jakoukoliv přípravnou práci, která je potřeba k vykonání požadavku, když se dostane na začátek fronty.
Protože požadavky na vyřazení prochází frontou se všemi ostatními blokovými požadavky, mohou být manipulovány kódem I/O plánovače. Konkrétně mohou být slučovány, čímž se zredukuje počet požadavků a objevuje se možnost, že počet sektorů dohromady bude dost velký na to, aby se uvolnil celý výmazový blok. Je zde ale nebezpečí: souborový systém může vyřadit sadu sektorů, potom do nich zapsat nová data poté, co jsou alokována do nového souboru. Byla by vážná chyba změnit pořadí operací a nový zápis přesunout před vyřazování, protože nová data by se ztratila. Vyřazující operace tedy bude potřebovat nějakou I/O bariéru, která zabrání změnám pořadí před a po vyřazení. Bariérové chování by se ale mohlo zahodit u souborových systémů, které jsou schopné provádět své vlastní řazení požadavků.
Kromě souborových systémů mohou občas potřebovat vyvolat požadavek na vyřazení ostatní programy; David uvádí jako příklad mkfs, který by mohl vyřadit celý obsah zařízení před vytvořením nového souborového systému. Pro aplikace tohoto typu je nové ioctl() volání (BLKDISCARD), které vytvoří požadavek na vyřazení. Není potřeba říkat, že programy používající tuto vlastnost by měly být ojedinělé a velmi opatrně napsané.
Davidův patch zahrnuje ladění pro mnoho souborových systémů, což jim umožňuje vyvolat požadavek na vyřazení, když je to vhodné. Některé z nízkoúrovňových flashových ovladačů byly také aktualizovány. Co v tomto okamžiku chybí, je oprava obecného ATA ovladače; ta bude potřeba pro zprovoznění vyřazovacích požadavků na flash zařízeních, které používají zabudované překladové vrstvy - což je v současnosti většina zařízení na trhu. To by ale měl být relativně malý kousek skládačky; jsou dobré šance, že tento patch bude ve stavu vhodném pro začlenění do 2.6.28.
Před dávnými časy by distribuce Linuxu byla nainstalována s adresářem /dev plně zaplněným soubory zařízení. Většina z nich reprezentovala hardware, který na instalovaném systému nikdy nebude přítomen, ale byly potřeba, kdyby náhodou. Ke konci této éry nebylo výjimečné nalézt systémy s okolo 20 000 speciálními soubory v /dev a počet rostl. Toto schéma bylo přinejmenším nepraktické a rostoucí počet vyměnitelných zařízení (a zařízení obecně) hrozil tím, že se celá struktura zhroutí vlastní vahou. Zjevně bylo potřeba něco udělat.
Po malou chvíli se zdálo, že to něco může být devfs, ale tenhle příběh neskončil dobře. Skutečným řešením nepořádku v /dev/ se ukázal být nástroj nazvaný udev původně napsaný Gregem Kroah-Hartmanem. Udev reaguje na události přidání a odstranění zařízení, o kterých ho informuje jádro, a vytváří či odstraňuje speciální soubory v /dev. Postupem času udev získal větší možnosti, jako je například schopnost spustit externí programy, které pomáhají vytvořit trvalá jména pro přechodná zařízení. Udev je nyní klíčovou komponentou v téměř všech linuxových systémech. Je jako potrubí v domě; většina lidí si ho nikdy nevšímá, dokud se nerozbije. Pak si uvědomují, jak důležitá komponenta to skutečně je.
Udev se konfiguruje sadou pravidel, které jsou na většině systémů uloženy v /etc/udev/rules.d. Tato pravidla specifikují, jak mají být pojmenovávána zařízení, kdo je má vlastnit a jaká mají být oprávnění, které jaderné moduly se mají nahrát, které programy se mají spustit, a tak dál. Sada pravidel pro udev také umožňuje distributorům a správcům systémů ladit chování systému spojené se zařízeními tak, aby vyhovovalo lokálním potřebám a chuti.
Nebo možná ne. Správce udevu Kay Sievers dal nedávno najevo, že by byl rád, aby distributoři používali sadu pravidel dodaných s programem samotným. Kay říká:
Měli bychom se všichni sjednodit tak, jak je to jen možné. Red Hat, SUSE a Gentoo již používají stejné soubory s pravidly s minimem pravidel navíc v souboru specifickém pro distro. Žádáme zbytek vesmíru, aby se k nám přidal a udělal to samé.
Tento požadavek některé překvapil. Linuxový systém je plný utilit s konfiguračními soubory v /etc; obvykle není na všechny distribuce tlak, aby používaly stejné. Proč by tedy všechny distribuce měly používat stejnou sadu pravidel pro udev? Zdá se, že hlavní jsou tyto argumenty:
Pravidla pro udev ve skutečnosti nejsou konfigurační soubory - místo toho jsou kód psaný v jazyce specifickém pro doménu. Změna těchto souborů je podobná patchování C kódu pod nimi; to rozhodně není neslýchané, ale obecně se to nepovažuje za žádoucí. Aby tento argument podpořili, vývojáři udev přesouvají pravidla z /etc do /lib.
Nemá příliš smysl, aby se distribuce odlišovaly schématy pojmenovávání zařízení. Má naopak smysl, aby všechny linuxové systémy měly stejná jména pro zařízení. Pro situace, kde je smysluplné, aby se distribuce odlišovaly - například v tom, která skupina má zařízení vlastnit - je mechanismus pro přidání pravidel specifických pro distribuci.
Další balíčky následně závisí na specifickém nastavení udevu pro systém pod ním. Pro distribuce, které používají svá vlastní pravidla, je obtížnější tyto nástroje zprovoznit.
Poslední bod odkazuje konkrétně na DeviceKit, sadu nástrojů, která je určena k tomu, aby se zjednodušila správa zařízení. Udev a DeviceKit dohromady jsou určeny k tomu, aby nahradily většinu funkce často pomlouvaného nástroje hal. Vizte tento článek od Davida Zeuthena, kde se dozvíte více informací o DeviceKitu a přechodu od halu obecně.
Jediný problém je, že někteří distributoři nesouhlasí. Marco d'Itri, správce udev v Debianu, odpověděl, že společná sada pravidel pro udev "nebude". Výchozí pravidla nesplňují potřebu Debianu podporovat starší jádra a kromě toho Považuji svá pravidla za mnohem čitelnější a elegantnější, než jsou vaše. Správce v Ubuntu Scott James Remnant se také zdráhá použít výchozí pravidla.
Zdá se, že Scott je ochoten uvažovat o přechodu k výchozím pravidlům, pokud bude možné je změnit, aby fungovaly správně; Zdá se ale, že Marco je rozhodnut vytrvat. Když byl vybídnut, aby poslal patche, které by vylepšily výchozí pravidla (a zelegantil je), odpověděl:
Místo toho mi řekněte, co v mých pravidlech chybí, já to opravím a budete je moci použít. Jestliže nic nechybí, můžete je použít hned teď.
Zdá se pravděpodobné, že většina distributorů nakonec dojde k závěru, že udev pravidla jsou kód, který má být spravován v upstreamu; dokonce i Debian na to může nakonec přistoupit. Zatímco se to řeší, "instalatérská" vrstva, která sedí na jádře, by měla být přepracována do lepšího stavu. Jaderní vývojáři zjistili, že jsou v tomto procesu zahrnuti; David zaslal návrh, že ke všem novým subsystémům musí být dodána sada pravidel pro udev předtím, než budou začleněny. To by mohlo pomoci vývojářům udevu sestavit sadu pravidel předtím, než začnou mít distributoři pocit, že je potřeba zakročit, aby věci fungovaly.
Práce jádra je čím dál tím víc spojována se sadou nízkoúrovňových aplikací v uživatelském prostoru; není toho moc, co lze udělat s holým jádrem. Jak má tato nízkoúrovňová instalatéřina fungovat a jak má spolupracovat s jádrem, to se stále řeší. Správa pravidel udevu je jenom jedno z témat trvalých diskuzí. Nadcházející Linux Plumbers Conference (Konference linuxových instalatérů) se zdá být dobře načasovaná; je toho mnoho, o čem je potřeba mluvit.
Společnost pro výpočetní stroje [Association for Computing Machinery, ACM] vydala Revize operačních systémů [Operating Systems Review] s tématy, které se týkají linuxového jádra.tento preklad me prijde opravdu nestastny.... ACM bych neprekladal, stejne tak jako neprekladame IBM na ,,mezinarodni obchodni stroje''... a revize operacnich systemu... tady bych se asi taky nepoustel do prekladu, pripadne zvolil jiny vyznam slova ,,review'', napr. prehled...
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.