Portál AbcLinuxu, 29. dubna 2024 07:30
Aktuální verze jádra: 2.6.17.8. Citát týdne: Linus Torvalds. Marcelo Tosatti předává štafetu jádra 2.4. Filtrování SCSI příkazů. Diskuze o Reiser4 - znovu. Rozhraní pro jaderné události. Nová jádra a staré distribuce.
Aktuální předverze je 2.6.18-rc3, vydaná 29. července. Přísun patchů se zpomaluje úměrně s tím, jak začíná být nová verze stabilní. Takže tato předverze přidává několik oprav, ale nic moc navíc. Podrobnosti jsou v dlouhém changelogu.
Od vydání -rc3 bylo do hlavního repozitáře začleněno přes 100 oprav.
Aktuální -mm strom je 2.6.18-rc2-mm1. Mezi nedávné změny patří velká aktualizace x86-64 a NFS a spousta oprav.
Tvrdím, že rozdíl mezi špatným a dobrým programátorem je v tom, jestli považuje za důležitější svůj kód nebo datové struktury. Špatní programátoři se starají o kód. Dobří programátoři se starají o datové struktury a jejich vztahy.
Marcelo Tosatti oznámil vydání jádra 2.4.33-rc3, které obsahuje jen pár patchů. Zároveň dal na vědomí, že správcovství jaderné řady 2.4 přebírá Willy Tarreau, který již nějakou dobu připravoval sérii patchů "hotfix" pro 2.4. Marcelovi, který řadu 2.4 spravoval od verze 2.4.16, patří velký dík.
Pálení dat na CD nebo DVD je komplikovaný proces, při němž se používá velké množství SCSI příkazů. Takže každá aplikace, která vypaluje disky, musí mít schopnost posílat mechanice speciální SCSI příkazy. Těsně před vydáním jádra 2.6.8 se však vývojáři rozhodli, že aplikacím by nemělo být dovoleno posílat jakékoliv SCSI příkazy. Některé z těchto příkazů by mohly vést k přepsání firmwaru mechaniky, vznícení nebo nahrazení hudebních stop nahrávkami zpěvu Richarda Stallmana. Ve snaze zabránit těmto nežádoucím věcem začlenil Linus na poslední chvíli patch, který uživatelům bez dostatečných práv zakazoval posílat SCSI příkazy, jež nebyly na seznamu povolených v jádře.
Je skoro jisté, že žádný uživatel nezničil CD mechaniku jádrem 2.6.8. Jen málo z nich vůbec mohlo zapisovat na disky; filtrování bylo tak přísné, že uživatelé bez práv nemohli dělat nic užitečného. Pozdější aktualizace to napravily a s 2.6.10 už zase vypalování většině uživatelů fungovalo.
Ne však všem uživatelům. Jak nedávno poznamenal Dave Jones v konferenci linux-scsi, filtrování příkazů pořád působí potíže některým mechanikám Plextor. Utilita cdrecord se pokouší posílat těmto mechanikám speciální příkazy daného výrobce, ale jádro je nepustí. Všechno se zastaví a uživatel musí práci začít znovu jako root. Dave se ptal: nebylo by vhodné přidat k filtrovacímu kódu možnost výjimek pro příkazy specifické u různých výrobců?
Vývojáři blokového subsystému reagovali tak, že by se mělo prostě vyhodit celé filtrování příkazů. Tato funkce byla projednávána na nedávném setkání (storage summit) a účastníci se shodli, že by měla být odstraněna. James Bottomley shrnul:
Dovolíme-li uživatelům vypalovat CD, není možné je kontrolovat bezchybně, jak ukazuje tento případ. A když povolíme příkazy výrobců, určitě se najdou takové, které zformátují disk nebo zničí firmware...
Takže myslím, že je lepší vyhodit tu tabulku a přiznat, že nenabízíme žádné zabezpečení, než předstírat, že nějaké máme.
Vůči filtrovacímu kódu je několik výhrad. Jde o zápis pravidel do jádra, což všeobecně nebývá kladně přijímáno - i když v tomto případě jde vlastně o pokus rozlišit přístup k disku v mechanice a k mechanice samotné. Seznam příkazů nikdy nebude dokonalý. Vypadá to, že některé mechaniky potřebují slyšet speciální zaklínadla od výrobce, jinak odmítnou na disk zapisovat. Některé příkazy mají na různých mechanikách různé významy. Co je bezpečné pro vypalovačku CD, může být likvidační pro jiný typ SCSI zařízení. Nepomáhá ani to, že v jádře jsou ve skutečnosti dva různé filtry SCSI příkazů (jeden v drivers/scsi/sg.c, druhý v block/scsi_ioctl.c), které implementují různá pravidla. Všechny tyto důvody pravděpodobně přispěly k rozhodnutí účastníků setkání - odstranit filtrování.
Ten plán má jedinou malou chybku: Linus má na filtrování jiný názor:
Jinými slovy: filtrování příkazů z block/scsi_ioctl.c odstraníte jedině v jádře, které nespravuji já, nebo ho zrušíte jiným způsobem, který bude tak maskovaný, že si toho nevšimnu. Protože nejsem tak hloupý, abych si myslel, že je v pořádku nechat běžné uživatele nastavovat hesla ovladače nebo přepisovat firmware disku jen proto, že mají na zařízení právo zápisu. Berte to jako mé poslední slovo.
Takové prohlášení vypadá dost definitivně. Což však neznamená, že situaci nelze zlepšit. V současné době se prosazuje myšlenka nechat oprávněného uživatele provádět v tabulce pro filtrování příkazů změny. Distribuce by pak mohly dodávat nástroje, které rozpoznají problematická zařízení a podle toho upraví filtrovací tabulky. Celé by to mohlo být transparentně integrováno s funkcí hotplug. Jens Axboe napsal patch (původně byl autorem Peter Jones), který promění filtrovací seznam v samostatný objekt pro každé zařízení. Ten pak půjde nastavit prostřednictvím sysfs, takže každé zařízení by mohlo mít vlastní sadu výjimek.
Jak přesně by takové rozhraní pracovalo, to je třeba ještě prodiskutovat. Ale konfigurovatelné filtry pro každé zařízení zvlášť se zdají jako cesta správným směrem. Zůstává zachováno filtrování nebezpečných příkazů, ale rozhodování o pravidlech se přesunuje do uživatelského prostoru. Jakmile bude možné pravidla měnit, postarají se distributoři o to, aby byla jednotlivá zařízení dobře podporována. Nebo, pokud budou chtít, označí všechny příkazy jako povolené, a tím odstraní filtrování úplně.
Jestli Hansi Reiserovi nějaká vlastnost chybí, není to vytrvalost. V říjnu 2002 požádal o začlenění svého nového souborového systému reiser4 do vývojového jádra 2.5 předtím, než přejde do stabilizační fáze před vydáním 2.6. Uplynuly téměř čtyři roky, během kterých prošel reiser4 nekonečnými debatami v konferenci linux-kernel, mnoha změnami opravujícími nalezené problémy, odstraněním základních funkcí a dlouhým čekáním v jádře -mm. Přes to všechno stále reiser4 není v hlavním jádře - ale Hans se nevzdává.
Do této chvíle bylo nutno překonat množství překážek. Funkce "soubory jako adresáře" upravovala POSIXovou sémantiku způsobem, který některým lidem nebyl milý, a navíc způsobovala zásadní potíže se zamykáním; funkce byla odstraněna. Ne všichni pozorovatelé považují výsledky výkonnostních testů za důvěryhodné. Přetrvávají obavy z toho, jak se budou vývojáři reiser4 o souborový systém starat, jakmile bude začleněn. Hans je známý svými problémovými vztahy s ostatními vývojáři jádra a nereaguje vždy zrovna uhlazeně na (ne vždy zrovna uhlazené) komentáře kritiků. Výsledkem je trnitá cesta k začlenění souborového systému, který však skutečně nabízí zajímavé nápady a potenciálně špičkový výkon.
Částečně kvůli pocitu, že se proces začleňování reiser4 táhne už příliš dlouho, se do konference debata vrátila. Hans a spol. by rádi dosáhli zařazení reiser4 do jádra 2.6.19 a vypadá to, že by nakonec mohli uspět.
Stále je tu několik otázek, i když některé z nich možná nejsou tak problematické, jak si občas lidi myslí. Největší z nich je pravděpodobně koncept pluginů. Pluginy souborovému systému umožňují chovat se jinak ke každému uloženému souboru; je díky nim možné přidat funkce jako komprimaci nebo šifrování a další tajemné věci, které se teď dělají pomocí FUSE. Pluginy však ve vývojářské komunitě spustily hodně varovných signálů. Například Linus říká:
Dokud jim říkáte "pluginy" a chováte se k nim tak, nemám (a tuším, že spousta dalších lidí také ne) o to vůbec zájem. A abych řekl pravdu, spousta lidí si pomyslí, že hlavním účelem je buď podkopat copyrightová pravidla jádra, nebo přinejmenším vytvořit zmatek nekompatibilních sémantik bez rozumných pravidel pro zamykání atd.
Jeff Garzik si také dělá starosti:
Nechtěl bych zajišťovat technickou podporu pro distributora, za nímž přijde zákazník s padlým reiser4 v případě, kdy si zákazník tajně nahradil standardní inodovou strukturu dat interně napsaným pluginem a rovněž tajně nahradil adresářový algoritmus uzavřeným pluginem od VyberSiProdejce. Nechtěl bych se tím zmatkem probírat debuggerem.
Vývojáři chtějí, aby tvůrci reiser4 vzali na vědomí fakt, že podobný mechanismus, má-li vůbec smysl, by měl být implementován v rámci vrstvy VFS, ne v určitém souborovém systému. Reiser4 pluginy jsou vnímány jako samostatný, soukromý VFS, který může nadělat spoustu potíží.
Co si však mnoho lidí neuvědomuje, je to, že otázka pluginů je teď daleko méně problémová než bývala. Nelze je natáhnout za běhu, takže není nutné mít starost kvůli copyrightu jako u uzavřených jaderných modulů. A většina funkcí pluginů byla na základě komentářů odstraněna. Andrew Morton, který kód nedávno prohlížel, poznamenal:
Vypadá to, že jsou pluginy označovány za příliš velkého strašáka - jde jen o interní abstrakční vrstvu, která umožňuje pozdější čisté a bezpečné přidávání funkcí. Určitě nestojí za všechen ten povyk.
Podle Andrewa je největším problémem absence přímého I/O a podpory rozšířených atributů. Přímý I/O možná není příliš vzdálen, ale nevypadá to, že by mohly být v blízké budoucnosti připraveny i rozšířené atributy. To mimo jiné znamená, že by reiser4 nemohl mít podporu SELinuxu. Takové omezení by mohlo způsobit, že někteří distributoři vynechají podporu reiser4, i kdyby byla začleněna v hlavním jádře.
Zbývající stížnosti by mohly stačit k tomu, aby odradily některé uživatele či distributory od používání reiser4, ale zdá se, že nejsou dostatečné k tomu, aby zabránily zařazení do hlavní větve. Nový souborový systém se netýká těch, kteří jej nepoužívají, a problémy, které měli jeho uživatelé (například zamrzání) jsou snad už dávno pryč. Takže Hansovo dlouhé čekání se možná chýlí ke konci.
Článek o síťových kanálech z minulého týdnu naznačil, že kanály možná nejsou řešením budoucnosti. Od té doby proběhlo hodně diskuzí o tom, jak by se síťování mohlo pohnout kupředu - a kanály by mohly ještě hrát roli.
Na rozdíl od jiných operačních systémů postrádá Linux systémové volání pro obecné hlášení o událostech. Místo toho používají linuxové aplikace volání jako poll(), aby zjistily, kdy čeká nějaká práce. poll() bohužel problém neřeší úplně, takže aplikační smyčky událostí musí dělat komplikované věci, aby se vypořádaly například se signály. Zpracovávání asynchronního I/O v rámci tradiční linuxové smyčky událostí může být obzvlášť nepříjemné. Kdyby existovalo jediné rozhraní, který by aplikaci poskytlo veškeré potřebné informace o událostech, byly by aplikace mnohem jednodušší. Je to také příležitost k výraznému zvýšení výkonu.
Jsou dva návrhy linuxového rozhraní pro události: mechanismus kevent a API kanálu událostí navrhované Ulrichech Drepperem na letošním linuxovém symposiu v Ottavě. Ve výhodnější pozici je teď kevent, protože existuje funkční implementace, kterou si lze prohlédnout. Většina diskuze se tedy zaměřovala na to, jak kevent vylepšit.
Původní API kevent je považováno za trochu moc složité; závisí na jediném multiplexním systémovém volání (kevent_ctl()), což je přístup, který není všeobecně moc schvalován. Volání také vyžaduje, aby aplikace sestavila pole se dvěma různými typy struktur, a to je poněkud neohrabané. Jedním z prvních návrhů tedy bylo oddělit jednotlivé části API. Aktuální kevent patch (1. srpna) obsahuje nové systémové volání:
int kevent_get_events(int ctl_fd,
unsigned int min_nr,
unsigned int max_nr,
unsigned int timeout,
void *buf,
unsigned flags);
Toto volání by vrátilo mezi min_nr a max_nr událostmi a ukládalo by je postupně do buf, dokud by nevypršel timeout (určený v milisekundách). Parametr flags není v současné implementaci využit.
Na tomto rozhraní by šlo vylepšit hned několik věcí, ale jak se zdá, finální podoba bude pravděpodobně dost odlišná. Současné rozhraní i nadále vyžaduje častá systémová volání kvůli stahování událostí; linuxová systémová volání jsou sice rychlá, ale při velkém vytížení by stejně bylo lepší strávit pokud možno více času v uživatelském prostoru. Mohlo by to být možné při použití jiného přístupu k hlášení o událostech.
Nápad, o kterém se mluvilo, navrhoval namapování pole kevent struktur mezi jádrem a uživatelským prostorem. S takovým polem by se zacházelo jako s kruhovým bufferem a mohlo by být spravováno pomocí indexového mechanismu podobného kanálům, který by příliš nezatěžoval keš. Jádro by do bufferu ukládalo události ve chvíli, kdy se staly, a uživatelský prostor by je zpracovával. Kdykoliv by byla událost ke zpracování, aplikace by ji získala bez jakéhokoliv zásahu do jádra. Jakmile by takový mechanismus fungoval, mohlo by být volání kevent_get_events() nahrazeno prostým rozhraním "počkej na události" (ačkoliv glibc by téměř jistě nabídla synchronní funkci "získej události"). Výsledkem by bylo velmi rychlé rozhraní - zvláště při vysokém počtu událostí.
Stále je však potřeba vyřešit pár problémů. První se týká situace, kdy se buffer zaplní. Současné asynchronní I/O rozhraní neumožňuje, aby bylo více čekajících operací než je dostupných kontrolních blokových struktur; tak je zaručeno, že bude dost místa na hlášení o stavu každé operace. To může být důležité, protože ta část jádra, která chce provádět hlášení, často běží na úrovni softwarového nebo hardwarového přerušení. Pokud si však představíme použití kevents pro sledování tisíců otevřených soketů, neznámého počtu událostí týkajících se spojení atd., začne být čím dál více nepraktické alokovat všechny struktury událostí napřed. Při zaplnění bufferu se tedy bude muset provést něco chytrého.
Druhý problém se týká událostí "spuštěných úrovní" [level-triggered], které více odpovídají specifickému stavu než skutečné události, která proběhla. "Na tento soket lze zapisovat" je příkladem takové události. Když se pro zjišťování toho, jestli bude zápis blokován, používá rozhraní jako poll(), může jádro ověřit stav a okamžitě vrátit, je-li možné na daný popisovač souboru zapisovat. Hlášení takových věcí přes kruhový buffer je o dost těžší. Ať tak nebo tak, aplikace budou muset tento typ událostí zjišťovat přímo.
Vzhledem k tomu, že se jedná o exponované téma, je pravděpodobné, že se brzy objeví způsob, jak tyto potíže vyřešit. To by mohlo zamést cestu pro začlenění kevents do hlavního jádra třeba už v 2.6.20.
Utilita udev má jasně určený úkol: brát informace z jaderných událostí a virtuálního souborového systému sysfs a používat je k vytváření souborů zařízení odpovídajících skutečné konfiguraci systému. Když udev selže, je systém částečně nebo zcela nepoužitelný - situace, která se uživatelům obvykle dost nelíbí. Takže když Andrew James Wade nahlásil selhání udev při použití nedávného -mm jádra, vývojáři zpozorněli.
Ukázalo se, že problém je způsoben určitými změnami v sysfs, které mají zlepšit správu napájení. Konkrétní chybu lze opravit přidáním jiného patche, ale ten na oplátku vede k dalším potížím; několik distrucí přestává fungovat, protože verze udev, kterou dodávají, je příliš stará na to, aby rozuměla novému formátu sysfs. Andrew Morton si stěžoval, že Fedora Core 3 nefunguje, ale problém bude pravděpodobně rozšířenější.
Greg Kroah-Hartman, vývojář zodpovědný za změny, reagoval takto:
To distro už není podporované, že jo?
Jak dlouho bys chtěl, aby jádro podporovalo nepodporovaná komunitní distra, která jinak těží z faktu, že jsou rychle aktualizována? [...]
A ano, stáhnu z hlavního jádra ten patch, který lidi nutí upgradovat na udev z FC5, a počkám s ním na další verzi (minumum pak bude 081, která byla vydána v lednu 2006 - až bude venku 2.6.19, bude už 10 měsíců stará).
Andrew nebyl nadšen:
Jde mi (opět) o to, že se bavíme o zmrzačení _všech_ dister starších deseti měsíců. Nehrajeme si přeci na "ahá, ale to už nepodporujeme"... Fakt blbé. Víš, jaké všechny stroje přestanou fungovat? Já tedy ne.
Mezi distribuce, které by s vydáním 2.6.19 přestaly fungovat, patří mimo jiné i Ubuntu 6.06 LTS ("dapper") a ještě nevydaný Slackware 11. Takže není překvapivé, že se takové změny nelíbily více lidem. Je dost pravděpodobné, že bude celá sada patchů stažena a znovu promyšlena.
Greg však pokládá zásadní dotaz: Jak dlouho by se měla komunita starat o distro po té, co jej opustili jeho tvůrci? Tradiční odpověď by zněla "navždy", ale s novou generací nástrojů, které přenášejí "jádro do uživatelského prostoru", je těžké takový slib dodržet. Nástroje jako udev jsou těsně propojené se souborovým systém sysfs, který je zase téměř přímou reprezentací interních jaderných datových struktur. Sysfs svým způsobem funguje jako interní jaderné API, ale ve skutečnosti jde o rozhraní pro uživatelský prostor. Udržovat jej stabilní a vyhýbat se problémům s nekompatibilitou se staršími uživatelskými nástroji dá hodně práce. Navíc to ztěžuje skutečnost, že se vývojáři jádra pořád snaží vymyslet, jak by měl sysfs vlastně fungovat.
Na letošním jaderném summitu se mluvilo o přibalení nástrojů jako udev ke zdrojovým kódům jádra a distribuování celého balíku dohromady. Nová jádra by byla vždy doprovázena novými funkčními verzemi udev a některé z problémů s nekompatibilitou by zmizely. Není však možné takto přibalit neomezené množství nástrojů a každopádně je těžké vnímat takový přístup jako cokoliv jiného než hack pro obejití skutečného problému, který představuje udržování stability tak širokého a komplexního ABI.
Tento konkrétní problém bude pravděpodobně tak či onak zažehnán, ale určitě nebude poslední. Budou-li vývojáři jádra i nadále slibovat věčně stabilní uživatelské ABI, budou muset řešit všechny jeho aspekty - ne jen systémová volání. Nebude to snadné: moderní systémy vyžadují komplexní komunikační možnosti mezi jaderným a uživatelským prostorem. Ale vývojáři už vyřešili spoustu nelehkých problémů; s ohledem na zvýšenou pozornost, která je věnována zpětné kompatibilitě ABI, je pravděpodobné, že si poradí i s tímto.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.