23.2.2007 00:32
CIJOML | skóre: 58
| Praha
Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
Portál AbcLinuxu, 18. dubna 2024 18:12
Aktuální verze jádra: 2.6.20-rc7. Citáty týdne: Dave Airlie, Matt Mackal. Vývoj ovladačů pro Linux zdarma. Shrnutí API změn v 2.6.20. Síťové jmenné prostory. Fibrily a asynchronní systémová volání.
Aktuální předverze řady 2.6 je 2.6.20-rc7, vydaná 30. ledna. Linus k tomu řekl: No jo, vím, řekl jsem, že bude jen -rc6 a pak už finální 2.6.20, ale věc se má tak, že seznam známých regresí se nezmenšil tak rychle, jak jsem doufal, a proto máme ještě -rc7. V této verzi je slušná řádka oprav, ale nic moc jiného.
2.6.20-rc6 vyšla 24. ledna. Obsahuje také dost oprav a dva nové ovladače pro paměťová zařízení (flash).
Od vydání -rc7 zatím do hlavního repozitáře žádné patche nepřibyly.
Aktuální verze -mm stromu je 2.6.20-rc6-mm3. Mezi nedávné změny patří velká aktualizace ACPI, nová sada patchů pro dynamický čas a časovač s vysokým rozlišením, podpora stínových adresářů v sysfs, preemtibilní RCU a velká hromada pročišťovacích patchů pro sysctl().
Starší jádra: 2.6.16.39 bylo vydáno 31. ledna. Opravuje relativně malé množství problémů, z nichž žádný se přímo netýkal bezpečnosti.
K vytvoření komunitního ovladače pro jakýkoliv grafický procesor, ke kterému je dostupná specifikace, je potřeba příliš mnoho času. Pokud ten ovladač neudělá sám výrobce nebo za to někomu nezaplatí, je malá šance, že by byl ovladač v použitelném stavu v době, kdy je produkt ještě v prodeji.
-- Dave Airlie
Takže ano, pokud uživatel nahlásí problém, který lze připsat chybě v jediném bitu paměti [single bit memory error], a není možné jej reprodukovat ani vysvětlit, je úplně normální to svést na kosmické záření, dokud nepůjdou z hlášení o chybách vypozorovat nějaké souvislosti.
-- Matt Mackall
Greg Kroah-Hartman učinil výrobcům hardwaru nabídku: komunita vývojářů jádra pro vás bude psát ovladače zadarmo. Už se nemusíte trápit se všemi těmi příklady v Linux Device Driver Kit nebo se probírat tisíci ukázkovými ovladači ve snaze objevit takový, který by se nejvíce podobal tomu, co potřebujete. Není na tom samozřejmě nic nového, ale jde o jasný popis výhod poskytnutí informací o hardwaru.
Přestože v době psaní tohoto textu ještě jádro 2.6.20 nevyšlo, nebude to trvat dlouho. Veškeré změnu interního API měly proběhnout nejpozději před měsícem, takže mělo by být bezpečné sepsat shrnutí těch nejvýznačnějších. Pro tuto verzi jich bylo docela dost a některé způsobily v kódu pořádné vlny.
Nová funkce:
int device_move(struct device *dev, struct device *new_parent);
Změní předka daného zařízení na new_parent, přičemž provede potřebné sysfs změny a vygeneruje speciální událost KOBJ_MOVE pro uživatelský prostor.
Pokud už se těšíte na to, co bude v 2.6.21, tak několik věcí lze odhadnout už teď. Je pravděpodobné, že budou odstraněny staré příznaky SA_*, které se používaly s request_irq(); místo nich by měly být používány nové příznaky IRQF_*. Na další vývojový cyklus čeká také změna API časovače. Kromě toho si můžeme být jisti, že se chystá i nějaké to překvapení.
V poslední době se věnuje hodně pozornosti hypervizorům a plně virtualizačním (nebo paravirtualizačním) řešením. Příznivci kontejnerového konceptu - při kterém běží všechny virtualizované systémy v pečlivě oddělených prostředích na hostitelském jádře - se příliš neprojevovali. Rozhodně však nezaspali, jak je vidět z úsilí, které je věnováno síťovým jmenným prostorům.
Aby kontejnerový přístup fungoval, musí být každý globální zdroj v systému zabalen do nějakého jmenného prostoru. To už bylo provedeno pro některé relativně jednoduché zdroje, například informace utsname nebo ID procesů; části výsledného kódu už si i našly cestu do jádra. Jenže pro kontejnery, které jsou zcela izolované od okolního světa, není příliš užití; obyčejně je potřeba nějaká schopnost síťovat. Kontejnery mohou být například užitečné pro uzavření webového prohlížeče (což jej drží pryč od zbytku systému pro případ, že by byl napaden) nebo webserveru - ale pouze pokud funguje síťování. Kontejnery by však neměly vidět pakety jiných kontejnerů a, pokud možno, by měly mít možnost se vázat na stejné porty, aniž by si navzájem překážely.
Aby to fungovalo, jsou potřeba síťové jmenné prostory. Tyto jmenné prostory virtualizují přístup ke všem síťovým zdrojům - rozhraní, čísla portů atd. - což každému kontejneru umožňuje přístup k síti, který potřebuje (ale nic více). Jako každý počítačový problém, i síťové jmenné prostory mohou být řešeny další vrstvou. S takovým přístupem je však trochu problém: síťovací kód je velká hromada komplexního a pečlivě vyladěného kódu, o nějž se starají vývojáři, kteří nemají moc pochopení pro změny, které by mohly přinést výkonnostní režii nebo potenciální chyby. Dosáhnout začlenění implementace síťových jmenných prostorů bude vyžadovat pořádný kus velmi citlivé a opatrné práce.
Jeden přístup je možné vidět v sadě patchů s síťovými jmennými prostory L2, kterou nedávno poslal . Tyto patche se zaměřují na spodní úrovně síťového stacku ve snaze založit řádné jmenné prostory pro síťová zařízení a IPv4 vrstvu. Aby se minimalizoval dopad na ostatní síťovací kód, zavádí L2 patch myšlenku "aktuálního síťového jmenného prostoru", který je držen v proměnné na každém procesoru. Aktuální jmenný prostor je implementován jako stack s operacemi push [dej] a pop [vezmi]; teoreticky to umožňuje provádění všech síťových operací v rámci jmenného prostoru. Nepodařilo se mi [Jonathan Corbet] uvěřit, že by to mohlo fungovat společně s jakoukoliv jadernou preempcí, ale možná jsem se jen špatně díval.
Struktura net_device dostává pole net_ns, které obsahuje jmenný prostor, k němuž zařízení náleží. Je to nastaveno na jmenný prostor aktuální ve chvíli vytvoření zařízení. Funkce pro vyhledávání zařízení jsou si teď vědomy jmenných prostorů; pokud zařízení nepatří k aktuálnímu jmennému prostoru, bude neviditelné. Pro každý jmenný prostor je zvlášť vytvořeno loopback zařízení. Kód pro IPv4 routování byl rozšířen tak, aby měl každý jmenný prostor své routovací tabulky. A kód, který přiřazuje příchozí pakety k soketům, také se jmennými prostory spolupracuje; pořád je jediná hashovací tabulka, ale jmenný prostor byl přidán do rozřazovacích kritérií.
Síťová rozhraní pro skutečný hardware zůstanou i nadále v kořenovém jmenném prostoru. Komunikaci s ostatními jmennými prostory zajišťuje "virtuální ethernetové" zařízení, které je součástí patche. Virtuální zařízení si lze představit jako spojení s vyhrazeným jmenným prostorem; vytvoří zařízení v rámci jmenného prostoru a také v předkovi (obyčejně root). Pakety zapsané na jedno zařízení se objeví na druhém. Díky přidání několika směrovacích pravidel v kořenovém jmenném prostoru mohou být pakety, které splní stanovená kritéria, poslána do (nebo ven z) konkrétních jmenných prostorů.
L2 patch poskytuje základy pro vytvoření malých virtualizovaných internetů v rámci jediného systému, ale ještě není k dispozici úplná izolace. Proces může ve svém jmenném prostoru překonfigurovat rozhraní, což by mohlo způsobit problémy pro celý systém. Řešení nabízí patch vytvářející jmenné prostory L3, který poslal Daniel Lezcano. Jmenný prostor L3 je vždy potomkem L2; je to však slepá ulička - sám už potomky mít nemůže. L3 také nemá žádné možnosti správy sítě; jakmile je takový jmenný prostor vytvořen, musí si vystačit s konfigurací, kterou mu přidělil předek.
Výsledkem je, že by uzavřený systém mohl být vložen do jmenného prostoru L3, a měl by tak mít možnost provádět síťování bez zásahu do ostatních systémů v jiných jmenných prostorech (dokonce bez toho, aby je viděl).
Trochu jiný přístup je patrný u patchů se síťovými jmennými prostory od Erica W. Biedermana. Eric, maje na vědomí problémy spojené se začleňováním síťových jmenných prostorů, se daleko více stará o vlastní proces než o konkrétní implementaci. Jeho patche se tedy zaměřují hlavně na to, aby bylo správné interní API.
První úkol je vymyslet, jak budou síťové jmenné prostory reprezentovány. Místo struktury zvolil Eric mechanismus, který určitým způsobem označuje všechny síťovací globální zdroje. Tyto zdroje jsou nalinkovány do speciální sekce jádra, která může být klonována při vytvoření nového jmenného prostoru. Každá globální proměnná se stane offsetem do sekce vztahující se ke každému jmennému prostoru; přistupovat se musí pomocí speciálního makra. Tento způsob se zdá obtížný, ale má pár výhod. Je-li natažen modul s proměnnými specifickými pro jmenný prostor, mohou být tyto proměnné do každého existujícího jmenného prostoru přidány za běhu. A pokud nejsou jmenné prostory používány, spadne režie celého mechanismu na nulu. To je důležitá vlastnost: aby existovala naděje na začlenění, implementace nebude smět mít vliv na systémy, které ji nepoužívají.
Patche (31 kousků) se pak propracovávají různými částmi síťovacího API, přičemž přidávají parametr pro jmenné prostory funkcím, které to potřebují. Ericovy patche nemají žádný koncept "aktuálního jmenného prostoru"; místo toho je to všude explicitní parametr. Takže například každá funkce, která vytvoří soket (existují ve všech implementacích protokolů), dostane parametr jmenného prostoru. Struktuře sk_buff (která reprezentuje paket) bude přiřazeno pole jmenného prostoru buď z procesu, který ji vytváří (u odchozích paketů), nebo ze zařízení, ze kterého byla přijata; příslušné funkce specifické pro daný protokol by ten jmenný prostor měly vzít na vědomí. Funkce, které se starají o netlink sokety, také dostanou parametry jmenného prostoru, podobně jako ty, které implementují vyhledávání síťových zařízení, generování událostí a Unix-domain sokety. Stejně jako L2 patche, i Ericova implementace obsahuje virtuální síťové zařízení (nazývané "etun"), které lze použít k routování paketů mezi jmennými prostory.
Na rozdíl od L2/L3 řeší Ericovy patche i virtualizaci síťových rozhraní v /proc, sysctl a sysfs. To vyžaduje podporu stínových adresářů v sysfs. Stínové adresáře uvolňují vazbu mezi sysfs a interní hierarchií kobject, což různým jmenným prostorům umožňuje vidět na stejném místě různý obsah.
Klíčovým aspektem Ericova patche je, že implementuje minimum mechanismu jmenných prostorů. Místo toho je velká část síťovacího stacku nucena testovat přidělený jmenný prostor a selhat, pokud není využíván kořenový jmenný prostor. Účelem je nejprve správně zvládnout rozhraní a potom po malých kouscích doplňovat mechanismus. Testy pojistí, že síťový stack uživatele nepřekvapí provedením nesmyslu, dokud nebude plně připraven na práci s nekořenovými jmennými prostory.
Přestože byly představeny všechny tyto patche, nijak zvlášť se nediskutovalo. Skoro se zdá, že vývojoři sítí to ještě neberou vážně. Samo od sebe však tohle téma nezmizí; i nadále je velký zájem o začlenění kontejnerových funkcí do hlavního jádra, takže dříve nebo později to přijde na přetřes.
Jaderná podpora asynchronního I/O je nekompletní a vždy taková byla. Ačkoliv některé druhy operací (například přímé I/O na souborový systém) fungují v asynchronním režimu dobře, mnohé jiné ne. Implementace asynchronních operací je mnohdy obtížná a zatím se nenašel nikdo, kdo by to zprovoznil. V jiných případech jsou už nějakou dobu v oběhu patche, které se však nikdy nedostaly do jádra; AIO patche mohou být dost invazivní a tím pádem je složité je začlenit. Ať už je důvod jakýkoliv, věci se v oblasti AIO pohybují velmi pomalu.
Zach Brown se rozhodl trochu rozvířit hladinu položením jednoduché otázky: co když je způsob, kterým jádro AIO implementuje, úplně špatný? Stávající přístup totiž věci dost komplikuje, protože vyžaduje explicitní zpracování AIO v každém subsystému, který to podporuje. Je potřeba předávat IOCB struktury a jádro musí pořád kontrolovat, jestli se má při dané operaci zablokovat, nebo vrátit jeden z kódů "pracuje se na tom". Bylo by mnohem lepší, kdyby šlo většinu jaderných operací prostě vyvolat asynchronně, aniž by bylo nutné je komplikovat explicitní podporou.
Zach tedy poslal předběžnou sadu patchů, která podporu asynchronního I/O výrazně zjednodušuje. Ale tím nekončí: zároveň umožňuje volat jakékoliv systémové volání v asynchronním režimu. Klíčem je nový druh lehkého jaderného vlákna nazývaný "fibril" [vlákno].
Fibril je prováděcí vlákno, které běží pouze v jaderném prostoru. Proces může mít libovolný počet aktivních fibrilů, ale v jednom okamžiku může být v procesoru prováděn jen jediný. Fibrily mají vlastní stack, ale jinak sdílejí všechny zdroje svého procesu-předka. Uchovávány jsou v linkovaném seznamu připojeném ke struktuře úlohy.
Když proces provede asynchronní volání, vytvoří jádro nový fibril a volání spustí v tomto kontextu. Pokud je dané systémové volání okamžitě ukončeno, je fibril zničen a výsledek je vrácen volajícímu procesu jako obvykle. Pokud se však fibril zablokuje, bude zařazen do fronty a kontrolu opět převezme volající kód, který pak může vrátit stavový kód "pracuje se na tom". "Hlavní" proces pak může běžet v uživatelském prostoru, zadat další asynchronní operace nebo si prostě dělat cokoliv jiného.
Dříve či později bude operace, která fibril zablokovala, dokončena. Struktura záznamu v čekací frontě byla rozšířena o informaci o tom, na čem byl fibril zablokován; probouzecí kód tento fibril najde a přidá do speciálního linkovaného seznamu "spouštěcí fronta" v struktuře úlohy předka. Jádra pak naplánuje spuštění fibrilu, čímž možná odstaví "hlavní" proces. Fibril trochu pohne s prací a zase se zablokuje nebo práci dokončí. Ve druhém případě je uschován ukončovací kód [exit code] a fibril je zničen.
Přesunutím asynchronních operací do samostatného vlákna Zachův patch velmi zjednodušuje jejich implementaci - až na několik výjimek nebude nutné jádro kvůli podpoře asynchronních volání měnit. Vytvoření fibrilů by mělo zajistit, že k začlenění dojde brzy - fibrily mají být méně nákladné než jaderná vlákna nebo běžné procesy. Jejich sémantika, založená na jeden-po-druhém, pomáhá minimalizovat problémy se souběžností, které by se jinak mohly objevit.
Uživatelské rozhraní začíná následující strukturou:
struct asys_input {
int syscall_nr;
unsigned long cookie;
unsigned long nr_args;
unsigned long *args;
};
Od aplikace se očekává, že dá požadované číslo systémového volání do syscall_nr; parametry daného volání jsou v args a nr_args. Hodnota cookie bude procesu předána po dokončení operace. Uživatelský prostor si může vytvořit pole takových struktur a předat je:
long asys_submit(struct asys_input *requests, unsigned long nr_requests);
Jádro pak spustí každý z těchto požadavků ve fibrilu a vrátí kontrolu uživatelskému prostoru. Začne-li proces zajímat, jak jeho požadavky dopadly, použije toto rozhraní:
struct asys_completion {
long return_code;
unsigned long cookie;
};
long asys_await_completion(struct asys_completion *comp);
Volání asys_await_completion() způsobí blok, který počká, dokud se nedokončí aspoň jedna asynchronní operace, a pak vrátí výsledek ve struktuře, na kterou ukazuje comp. Zároveň bude vrácena i hodnota cookie, která byla zadána na začátku.
Všiml jsem si [Jonathan Corbet], že aktuální verze asys_await_completion() nekontroluje, jestli jsou nějaké asynchronní operace právě prováděny; pokud ne, čekalo by volání dost dlouho. Celá sada patchů má několik problémů, o kterých však autor ví. Například se moc neuvažovalo o tom, jak by měly fibrily reagovat na signály. Zach neměl v úmyslu prezentovat hotové dílo, ale spíše nápad, aby se dozvěděl, co si o něm lidé myslí.
Linus byl nadšen:
Jupí! [...]
Velmi rád souhlasím, i když vlastní patche jsem prohlížel jen zběžně. Myslím, že jde o správný přístup, ale s detaily bude největší práce. Možná, že režie při alokaci stacku nebo nějaký jiný drobný avšak zásadní problém nakonec způsobí, že to nebude praktické. Ale velmi rád bych to začlenil.
Těch detailů je mnoho - Linus například poznamenal, že není omezeno, kolik fibrilů může proces vytvořit - ale vypadá to, že by byl rád, kdyby bylo AIO implementováno tímto způsobem. Připojil, že fibrily by se mohly hodit i v kódu kevent.
Ingo Molnar je naopak proti fibrilům; jeho argumentace je dlouhá, ale stojí za přečtení. Ingo říká, že existují jen dvě vhodná řešení pro jakýkoliv problém týkající se operačních systémů: 1) to, se kterým se nejlépe programuje, a 2) to, které nabízí nejlepší výkon. V oblasti I/O jsou nejjednodušší synchronní I/O volání a procesy v uživatelském prostoru. Nejrychlejší přístup pak bude "ryzí a minimalistický stavový stroj" optimalizovaný pro konkrétní úkol; svůj web server Tux dává jako příklad.
Podle Inga neslouží fibrily ani jednomu z těchto účelů:
Kam spadají všechny ty nápady na LWP, vlákna, fibrily, mikro-vlákna nebo N:M? Většinou jen oslabují koncept číslo jedna. A proto nakonec prohrají, jelikož číslo jedna je o programovatelnosti a ty nápady nenabízejí nic nového: protože nemohou. Buď chcete programovatelnost nebo výkon. Žádná střední cesta v jádře neexistuje!
Ingo tvrdí, že Linux je při přepínání mezi běžnými procesy dostatečně rychlý a že výhody, které nabízejí fibrily, jsou přinejlepším minimální a nestojí za to.
Tyto patche jsou v raném stadiu a bude ještě chvíli trvat, než bude jasné, jak to dopadne. I kdyby s nimi vývojáři souhlasili, může se stát, že proces přeměny na robustní jadernou funkci by byl příliš náročný na to, aby se vyplatily. Je to však zajímavý nápad, který nabízí nový pohled na způsob provádění AIO v jádře, takže je těžké si příliš stěžovat.
Dvakrat ti tam ujelo dvojpismenko...To by mě zajímalo, kde se tam tyhle chyby berou. Ve včerejším článku také. Spellcheck je však v době vkládání na server nehlásí, takže bych se vsadil, že v redakčním systému řádí šotek.
Nechci rýpat, po opravení smažte tenhle komentářTakové "rýpnutí" není ke škodě
.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.