3.4.2009 01:08
saly | skóre: 22
| blog: odi_et_amo
Rozbalit Rozbalit vše Re: Jaderné noviny - 4. 3. 2009
Portál AbcLinuxu, 23. dubna 2024 13:05
Aktuální verze jádra: 2.6.29-rc7. Citáty týdne: Steven Rostedt, Linus Torvalds, Darren "Slušňák" Hart, Andrew Morton. Aby NetworkManager fungoval při uspávání/probouzení. Přerušení, vlákna a lockdep. Xen: dokončovací práce. Zrychlení vypisování ftrace. Shrnutí interních změn API 2.6.29.
Současné vývojové jádro 2.6 je 2.6.29-rc7 vydané 3. března. Obsahuje dlouhý seznam oprav, nové ovladače pro gigabitové ethernetové adaptéry Atheros L1C, IEEE1394 adaptéry FireDTV a nějaká zlepšení chování v situaci, kdy souborovému systému btrfs dojde volné místo. Detaily vizte v kompletním changelogu.
Tento týden nebyly vydány žádné stabilní aktualizace 2.6.
+ /* + * Pifutex má vlastníka, ujistíme se, že jsme to my, pokud + * ne, stěžujeme si do uživatelského prostoru + * FIXME_LATER: vyřešit to slušně + */ + pid = curval & FUTEX_TID_MASK; + if (pid && pid != task_pid_vnr(current)) + return -EMORON;
-- Darren "Slušňák" Hart (díky Bertu Wesargovi)
Každý, kdo cestuje s uspaným laptopem, pravděpodobně narazil na otravný problém NetworkManageru, který se pokouší připojit do staré sítě - do té, kterou jste opustili před nastoupením do letadla. Zdá se, že Dan Williams problém vyřešil a zaslal sadu patchů, které ho opravují. Ovladače přiřazují časové značky wifi sítím, o kterých ví. Tímto způsobem lze zjistit, jestli jsem síť viděl před vteřinou, před sedmi vteřinami, nebo tak dávno, že je pro mě mrtvá. Všechny k tomu ale využívají jaderný čítač 'jiffies'. A 'jiffies' se během uspávání/probouzení nezvyšuje. Už chápete, kam tím mířím? Jon Corbet, autor této zprávičky, plánuje při nejbližší příležitosti koupit Danovi pivo.
Felipe Balbi nedávno zaslal ovladač nazvaný twl4030-pwrbutton, který generuje vstupní události, když někdo stiskne vypínač připojený přes i2c řadič twl4030. V mnoha ohledech je to standardní ovladač; Felipe rozhodně nečekal, že kvůli tomuto zaslání vznikne dlouhá a zatrpklá diskuze, což je ale přesně to, co následovalo. Během této diskuze její účastníci načrtli některé problémy způsobu, jakým jsou v Linuxu obsluhována přerušení, společně s potenciálním řešením.
Věc začala, když Andrew Morton zpochybnil tento kousek kódu nalezený v obsluze přerušení v ovladači:
#ifdef CONFIG_LOCKDEP
/* WORKAROUND pro lockdep, který nám nutí IRQF_DISABLED, což
* nechceme a nemůžeme tolerovat. Ačkoliv by mohlo být přátelštějští
* nepůjčovat si kontext tohoto vlákna...
*/
local_irq_enable();
#endif
Workaroundy tohoto druhy bývají středem pozornosti horlivých revidovatelů. Porozumět tomuto konkrétnímu vyžaduje jenom trochu informací.
Kdysi ve Starých dobrých časech mělo linuxové jádro "rychlé" a "pomalé" obsluhy přerušení; hlavním rozdílem bylo to, že "rychlé" obsluhy běžely se zakázanou obsluhou přerušení, kdežto "pomalé" obsluhy s povolenou. Postupem času se rozdíly mezi těmito typy smazaly; rychlejší a chytřejší hardware a rozšířenější používání softwarových přerušení a taskletů zajistily, že na době zpracovávání přerušení téměř nezáleží. Většina autorů ovladačů tedy příliš nepřemýšlí o tom, jestli píší "pomalou" nebo "rychlou" obsluhu, i když toto rozlišování stále existuje. Pokud ovladač nepředá příznak IRQF_DISABLED, když požaduje přerušovací linku, jeho obsluha přerušení běží s povolenými přerušeními.
Když je povolen jaderný validátor zámků "lockdep", vytvoří detailní model toho, jak jsou v jádře používány zámky. Tento model lze použít k nalezení potenciálních deadlocků a dalších problémů. Podle Inga Molnára je lockdep poměrně efektivní:
Ukazuje se nicméně, že vývojáři lockdepu použili jeden významný zjednodušující předpoklad: všechny obsluhy přerušení se vykonávají se zakázanými přerušeními. Když je lockdep povolen, obecná vrstva obsluhy přerušení toto vynutí bez ohledu na to, jestli byla dotyčná obsluha registrována s příznakem IRQF_DISABLED. Lockdep tímto způsobem funguje už nějakou dobu a stížnosti jsou ojedinělé. Nicméně, jak lze vidět z patche citovaného výše, "ojedinělé" není to samé jako "žádné".
Ovladače zařízení připojených přes I2C pracují s několika zajímavými omezeními, z nichž většina je vynucena tím, že "sběrnice" i2c je ve skutečnosti pomalé dvoudrátové rozhraní. Takže i "rychlé" operace, jako je čtení registru v zařízení, jsou ve skutečnosti u i2c zařízení pomalé; jsou tak pomalé, že proces, který danou operaci provádí, by měl při čekání na výsledek spát. A tady se u obsluhy přerušení i2c zařízení objevuje problém, protože potřebují přistupovat k registrům v zařízení, ale spát nemohou.
Výsledkem je, že mnoho i2c ovladačů implementovalo něco, co je v podstatě obsluha přerušení ve vláknech. "Skutečné" přerušení jednoduše přerušení zamaskuje a probudí vlákno, které potom udělá skutečnou práci zahrnující komunikaci se zařízením. V případě ovladače twl4030 byla implementace ve vláknech provedena relativně formálním způsobem, ve kterém jsou zavolány obsluhy přerušení zařízení - ze speciálního jaderného vlákna - samotnou IRQ vrstvou. Tyto obsluhy ve vláknech nečekají, že by běžely se zakázaným přerušením - vskutku tak běžet nemohou - ale obecný IRQ kód přerušení vypne i tak, pokud je povolen lockdep. To je důvod, proč si tento patch přidělává potíže tím, že je zase zapne, když se lockdep používá.
V reakci na tuto diskuzi Peter Ziljstra zaslal patch, který vynucuje IRQF_DISABLED u všech ovladačů. Jeho argumentem bylo, že žádná obsluha přerušení by neměla běžet s povolenými přerušeními. Umožnit to znamená koledovat si o přetečení jaderného zásobníku, pokud přijde mnoho do sebe se vnořujících přerušení; také to, říká, podporuje povědomí o tom, že pomalé obsluhy přerušení jsou OK. Navíc by ovladače měly být schopny vykonávat obsluhu přerušení se zakázaným přerušením, protože na sdílené lince může přerušení zakázat jiný ovladač. Takže nedává smysl "opravit" lockdep tak, aby některé obsluhy mohly běžet s povoleným přerušením; místo toho by měl být předpoklad 'vždy zakázané' přenesen do systému jako celku.
Odpověď na tento patch byla povětšinou souhlasná, alespoň obecně. Nastavit IRQF_DISABLED jako výchozí dává pro většinu zařízení smysl. Jsou však ovladače, které potřebují běžet s povoleným přerušením; například IDE ovladače, které používají programované I/O (PIO). Pokud bude těmto obsluhám dána exkluzivní kontrola nad systémem, ostatní zařízení budou mít neakceptovatelné latence, operace budou selhávat nebo se začnou zahazovat data. Jakákoliv změna tohoto typu tedy musí být provedena opatrně a musí zůstat možnost, aby obsluha běžela s povoleným přerušením.
A vynucení IRQF_DISABLED samozřejmě nijak nepomáhá vyřešit problém s twl4030.
Skutečným řešením by bylo mít obecnou podporu pro obsluhy přerušení ve vláknech. Strom realtime preempce takové obsluhy podporuje již nějaký čas; nedávno byl zaslán patch s variantou obsluhy ve vláknech ke zvážení pro hlavní řadu. Obsluhy přerušení ve vláknech mají mnoho výhod i nad rámec řešení problému diskutovaného zde; mohou zlepšit latence, umožnit priorizovat obsluhy přerušení a časem možná umožnit úplné odstranění softwarových přerušení. Zdá se tedy, že by mělo cenu tento kód začlenit.
Za tímto účelem se Thomas Gleixner vrátil s novou verzí patche obsluh ve vláknech. API vypadá v podstatě stejně jako v předchozí verzi, ale mohlo by se změnit v reakci na některé komentáře v revizích, které se objevily. Tato infrastruktura v podstatě umožňuje ovladači registrovat "rychlou obsluhu", která potvrdí (a zamaskuje) přerušení; pak zde je také běžná obsluha, která se zavolá buď v tvrdém [hard] přerušení nebo v kontextu procesu v závislosti na návratové hodnotě rychlé obsluhy. API umožňuje ovladačům dál fungovat bez modifikací nebo se změnit a používat obsluhu ve vláknech.
David Brownell, vedoucí kritik chování lockdepu a nápadu zakázat přerušení pro všechny obsluhy, zdá se, souhlasí s tím, že obsluha přerušení ve vláknech by měla být schopna vyřešit problém i2c. Všechny obsluhy přerušení ve vláknech z nutnosti poběží s povolenými přerušeními, takže hlavní potíž mizí. David by rád viděl nějaké změny, které by umožnily lepší podporu zřetězení obsluh, které je v takových situacích typicky potřeba, ale není jasné, kolik změn je skutečně zapotřebí.
Ve shrnutí se zdá, že obsluhy přerušení ve vláknech budou další technologií, která bude převzata ze stromu realtime preempce. Je nicméně otázka, kdy se tak stane. Požadavek na změny API může věci poněkud zpomalit; také se objevily požadavky na příklady implementace obsluhy ve vláknech u různých typů ovladačů. Uspokojit tyto požadavky dost rychle, aby se stihly revize kódu před začleňovacím oknem 2.6.30, je tak trochu výzva. Tento kód by tedy mohl čekat o vývojový cyklus víc; bylo by ale překvapivé, kdyby to trvalo déle.
Bylo nebylo, Xen byl horké téma, co se virtualizace týče. Vývojáři Xenu měli fungující řešení pro Linux - používající svobodný software - v mnohem pokročilejším stavu než všichni ostatní a Xen se zdál být budoucností virtualizace v Linuxu. Poté následovalo mnoho spekulativního kapitálu, distributoři se předháněli v tom, kdo první nabídne virtualizaci založenou na Xenu. Zdá se ale, že během cesty se Xen ztratil. Vývojáři XenSource často dávali najevo svůj malý zájem o začlenění kódu do hlavní řady a pokusy ostatních to udělat narážely na nekončící množství překážek. Xen tedy zůstal po mnoho let mimo hlavní řadu; první veřejné vydání Xenu se objevilo roku 2003, ale základní kód Xenu byl začleněn až do 2.6.23 v říjnu 2007.
Mezitím se objevilo KVM a převzalo většinu pozornosti. Jeho cesta do hlavní řady byla oslnivě rychlá a mnoho jaderných vývojářů se nestydělo vyjadřovat své preference přístupu, který KVM používá. Nedávno Red Hat věci trochu formalizoval oznámením "virtualizační agendy" založené na KVM. Mezitím se objevil lguest jako rychlý úvod pro ty, kteří si chtějí hrát s virtualizačním kódem.
Příběh o Xenu je klasický příklad odůvodněnosti pravidla "nejprve do upstreamu", které říká, že kód by měl být nejprve začleněn do hlavní řady předtím, než je distribuován zákazníkům. Distributoři chvátali s tím, aby mohli Xen dodávat, načež zjistili, že podporují kód mimo strom, který často nebyl podporován svými autory. Vydávané verze Xenu konkrétně často fungovaly pouze se starými jádry, což přidělávalo spoustu práce distributorům, kteří chtějí dodávat něco současnějšího. Přinejmenším někteří z těchto distributorů nyní přecházejí k jiným řešením a jaderní vývojáři na nejvyšších úrovních zpochybňují, jestli v současnosti vůbec má cenu začleňovat zbývající kód Xenu.
Shrnuto se zdá, že Xen má před sebou svou poslední hodinku. A nebo možná byly pověsti o skonu Xenu poněkud přehnané.
Kód v hlavní řadě implementuje koncept Xen "DomU" - neprivilegované domény bez přístupu k hardwaru. Plná implementace Xenu nicméně vyžaduje víc než to; je zde hypervizor v uživatelském prostoru (který má licenci GPL) a jaderný kód "Dom0". Dom0 je první doména, kterou spouští hypervizor; typicky běží s více privilegii než ostatní hosté Xenu. Účelem Dom0 je opatrně předávat privilegia dalším doménám Xenu, poskytovat jim přístup k hardwaru, síťovým rozhraním atd. podle nastavení správcovské politiky. Skutečná implementace Xenu musí obsahovat kód Dom0 - v současnosti velký kus kódu mimo strom.
Jeremy Fitzhardinge by tuto situaci rád změnil. Zaslal sadu patchů jádra Xen Dom0 s cílem začlenit ji do 2.6.30. Mezi komentáři revidovatelů byl tento dotaz Andrewa Mortona:
Otázky, které Andrew položil, byly v podstatě (1) jaký kód (kromě v současnosti zaslaného) je potřeba k dokončení práce a (2) je opravdu důvod to dělat? Odpověď na první otázku je další dvě až tři podobně velké série, které zajistí, že bude možné nabootovat dom0 bez dalších úprav. Potom jsou zde další kousky, které se do hlavní řady možná nikdy nedostanou. Začlenění hlavních částí do hlavní řady, říká Jeremy, by nicméně zmenšilo patche mimo strom, které musí udržovat distributoři a obecně všem zjednodušilo život. Co se druhé otázky týče, Jeremy odpovídá:
Krom toho Jeremy argumentuje, že Xen má stále důvod k existenci. Jeho návrh je mnoha způsoby zásadně odlišný od KVM; excelentní popis těchto rozdílů vizte v této zprávě. Výsledkem je, že Xen je užitečný v odlišných situacích:
Některé výhody, které Jeremy popisuje, zahrnují:
Přístup Xenu k tabulkám stránek odstraňuje potřebu stínových tabulek stránek [shadow page tables] nebo vnořování tabulek stránek [page table nesting] v hostech; to u mnoha druhů zátěže významně zlepšuje výkonnost.
Hypervizor Xenu je odlehčený a může běžet samostatně; hypervizor KVM je místo toho v jádře. Zdá se, že někteří výrobci (jmenováni jsou HP a Dell) dodávají hypervizor Xenu v mnoha svých systémech; jedná se mezi jinými věcmi o kód za vlastností "okamžité zapnutí" [instant on].
Podpora paravirtualizace v Xenu mu umožňuje fungovat na hardwaru, který nepodporuje plnou virtualizaci. KVM potřebuje podporu v hardwaru.
Oddělení hypervizoru Dom0 a DomU zjednodušuje bezpečnostní ověřování. Oddělení domén také umožňuje divoké konfigurace, ve kterých je každé zařízení řízeno jinou doménou; dalo by se to považovat za určitý druh těžkotonážní architektury mikrojádra.
Naproti tomu výhody KVM mají podobu relativní jednoduchosti, snadného používání, plného přístupu k současným vlastnostem jádra atd. Podle Jeremyho mají oba způsoby v Linuxu své místo.
Relativní ticho na konci diskuze naznačuje, že Jeremy se svou argumentací uspěl. V historii Xenu možná došlo k chybám, ale jde o projekt, který je stále naživu a má zjevně důvody k existenci. Autor článku předvídá, že kód Dom0 se setká v začleňovacím okně 2.6.30 jenom s malým odporem.
Jaderný patch, který snižuje spotřebu paměti a zároveň poskytuje přibližně trojnásobné zlepšení výkonnosti je obecně považován za dobrou věc. Nicméně, pokud je k dispozici další, víceméně ekvivalentní - ale mnohem rychlejší - způsob, jak danou akci provést, lze ho prohlásit za zbytečnou optimalizaci. Nedávný patch funkce ftrace_printk() má tyto vlastnosti, nicméně možnost získat takovéto zrychlení, i když v něčem, co je spíš pohodlné než potřebné, by mohlo trumfovat nad obavami o potřebnosti.
Lai Jiangshan navrhl přidání binární verze ftrace_printk() loni v prosinci; Frederic Weisbecker tyto patche převzal a zaslal k začlenění do ftrace. Základním nápadem je, že místo konverze argumentu na řetězec - jak to specifikuje formátování argumentů ve stylu printk() - by ftrace_bprintk() odložilo skutečnou konverzi až do doby, kdy je výstup čten z uživatelského prostoru. Místo toho by se do kruhového bufferu ukládaly binární hodnoty s ukazatelem na formátovací řetězec. Když se data sledování čtou z debugfs, formátovací řetězec a binární data jsou poskládána do výstupu.
Ingovi Molnárovi se tento přístup líbil, ale není spokojen s tím, že duplikuje většinu kódu v vsnprintf() ve dvou nových funkcích. Navrhl, že by mělo být možné vytáhnout společný kód: Měli bychom se mnohem více snažit sjednocovat tyto funkce místo vzdávání se a jejich duplikování. Frederic souhlasil, což nakonec vedlo k patchi, který dělí dekódování formátovacího řetězce do samostatné funkce.
Ingo také požádal o nějaká čísla, co se výkonnosti týče, ty Frederic poskytl jako součást patche. Rozdíl v paměti a čase zjistil přidáním:
ftrace_printk("This is the timer interrupt: %llu", jiffies_64);
do přerušení časovače. Spotřeba paměti byla méně než poloviční (16 versus 39 bytů na záznam) a úspora času byla také významná:
ftrace_printk: duration average: 2044 ns, avg of bytes stored per entry: 39 ftrace_bprintk: duration average: 1426 ns, avg of bytes stored per entry: 16
ftrace_printk: duration average: 8812 ns ftrace_bprintk: duration average: 2611 ns
Andrew Moton byl poněkud zmaten ze záměru patche: Snažit se zrychlit něco, co je z principu pomalé, se zdá být... divné. Ingo ale vysvětlil, proč to dává smysl:
Rozdělení formátovacího řetězce do jeho vlastní funkce format_decode() se z většiny setkalo se souhlasem, až na to, že seznam argumentů je poněkud ošklivý:
int format_decode(const char *fmt, enum format_type *type,
int *flags, int *field_width, int *base,
int *precision, int *qualifier)
Linus Torvalds navrhl použít struct printf_spec k uložení různých hodnot dekódovaných ze specifikace formátu a před funkce ukazatel na ni. Frederic souhlasil a přidal to do svých patchů, ale nedostal se s tím dostatečně daleko.
Linus si také myslel, že různým pomocným funkcím, které obsluhují specifické formáty (např. number(), pointer(), string() atd.) by se také měl předávat ukazatel na struct printf_spec. Jak upozorňuje: Když už pročišťujeme, tak to udělejme pořádně. Frederic opět rychle souhlasil; plánuje znovu zaslat patche reagující na tyto a další komentáře v blízké budoucnosti.
Krom toho, protože ftrace_bprintk() je náhrada za ftrace_printk(), navrhuje Frederic odstranění současného kódu ve prospěch rychlejší verze. Ingo tento přístup obhajuje:
I když jde o menší vylepšení relativně malého jaderného subsystému, poskytuje docela působivé zlepšení výkonnosti. Proces revidování jako bonus vyústil v nějaká pročištění, které pravděpodobně mělo být provedeno již dávno. I když platí argument, že tato úprava není skutečně zapotřebí, není příliš rušivá ani není příliš velká. To nakonec pravděpodobně bude dost k tomu, abychom ji nakonec viděli v hlavní řadě.
Jak se vývojový cyklus 2.6.29 blíží ke svému zakončení, je vhodné podívat se na interní změny API, ke kterým došlo. Následující seznam nemůže ani zdaleka být vyčerpávající, ale snad zachycuje hlavní body.
Ohromná sada patchů osobních údajů [credentials] byla začleněna. Tento kód reorganizuje správu osobních údajů procesu (ID uživatele, kvalifikace atd.) Jedním z okamžitých důsledků této změny je to, že přímé odkazování se na pole zaměřená na osobní údaje ve struktuře úlohy musí být změněno; například current->user->uid se mění na current_uid(). Popis nového API vizte v Documentation/credentials.txt.
Kód ftrace se dočkal mnoha interních změn. Sledování funkcí bylo v mnoha ohledech vylepšeno a vývojáři přidali mechanismus pro profilování chování příkazu if, poskytnutí grafu volání funkcí, získání sledování zásobníku v uživatelském prostoru a sledování přechodů mezi stavy napájení.
Většina funkcí/metod zpětných volání spojených se strukturou net_device byla z této struktury přesunuta do nové struct net_device_ops. Ovladače ve stromě byly konvertovány na nové API.
Ze struktury struct net_device; bylo odstraněno pole priv; ovladače by místo něj měly používat netdev_priv().
Obecná vrstva PHY má nyní podporu pro správu napájení. Za tímto účelem byly do struct phy_driver přidány dvě nové metody - suspend() a resume().
Síťová vrstva nyní podporuje operaci odlehčování při rozsáhlém příjmu [large receive offload] (či "obecné odlehčování při příjmu").
API NAPI bylo trochu pročištěno. Konkrétně funkce jako netif_rx_schedule(), netif_rx_schedule_pred() a netif_rx_complete() ztratily nepotřebný parametr struct net_device.
Souborová operace poll() nyní může spát; více informací o této změně vizte v tomto článku.
Mechanismus masek CPU, který se používá k reprezentaci sady procesorů v systému, je uprostřed rozsáhlého přepracování. Problém spočívá v tom, že masky CPU se často ukládají na zásobník, ale s tím, jak počet CPU roste, na zásobníku není pro masku dost místa. Nové API je navrhováno tak, aby tyto masky ze zásobníku zmizely a aby existovala ochrana proti tomu, kdyby se někdo někdy snažil je tam uložit. Detaily o této práci vizte v tomto oznámení od Rustyho Russela.
Byla začleněna infrastruktura pro asynchronní volání funkcí. Tento kód je nicméně stále ve vývoji a co se 2.6.29 týče, nebude aktivován při absenci parametru příkazové řádky jádra fastboot.
Byly začleněny funkce pro exkluzivní alokace I/O paměti.
Je zde nové synchronní hashovací rozhraní nazvané "shash". Zjednodušuje použití synchronních hashovacích operací a přitom umožňuje použít stejné tfm simultánně v různých vláknech. Všichni uživatelé ve stromě byli přepracováni na nové API.
Kód časovačů s vysokým rozlišením byl zjednodušen odstraněním proměnných režimů funkcí zpětných volání. Všechno zpracování nyní probíhá v kontextu tvrdého IRQ (hardirq).
Byla přidána nová sada LSM háčků; tyto podporují bezpečnostní operace založené na cestách [pathname]. Se začleněním těchto háčků byla odstraněna jedna hlavní překážka začlenění bezpečnostních modulů jako AppArmor a TOMOYO.
Jádro se nyní odmítne přeložit s GCC 4.1.0 nebo 4.1.1; tyto verze mají nepříjemné chyby, které brání vytvoření funkčního jádra. Verze 3.0 a 3.1 byly také prohlášeny za příliš staré a v 2.6.29 nebudou podporovány.
Ovladače Video4Linux nyní používají oddělenou strukturu v4l2_file_operations, ve které se ukládají jejich jako-VFS zpětná volání. Prototypy mnoha z těchto funkcí byly změněny, byl odstraněn parametr inode.
>Video4Linux2 nyní získal koncept "podzařízení", který má odrážet fakt, že video "zařízení" ve skutečností bývá sestava několika spolupracujících zařízení. Popis toho, jak tento mechanismus funguje, vizte v novém dokumentu.
Dvě nové funkce - stop_machine_create() a stop_machine_destroy() - umožňují nezávislé vytváření vláken používané funkcí stop_machine(). To umožňuje vytvořit tato vlákna před skutečným pokusem stroj zastavit, čímž je celá operace odolnější proti selhání.
Exporty mnoha SUNRPC funkcí byly změněny na pouze GPL.
Interní API MTD (memory technology device, zařízení paměťové technologie) doznalo významných změn zaměřených na podporu větších zařízení (těch, které vyžadují 64bitové velikosti.)
Vývojáři, které zajímá historie API změn, se mohou podívat na stránku API změn 2.6 na LWN. Po období nešťastného zanedbávání je tato stránka opět aktuální; Jon Corbet slibuje, že v udržování této stránky bude v budoucnu mnohem důslednější.
3.4.2009 01:08
saly | skóre: 22
| blog: odi_et_amo
Kdyby nacpali XEN do mainstreamu, tak by to bylo fajn. Myslel jsem, že už je to dávno mrtvé a s nepodporou hw virtualizace mam prostě u KVM smůlu.
Třeba se ještě někdy dočkám ve vanille podporu paravirtualizace 
Vanilla kernel se dá zkompilovat jako User mode linux, což bych osobně pro mnoho použití považoval za lepší. Minimálně není nutný žádný zásah do hostitelského systému. A pokud chce někdo provozovat něco "velkého", ať si to holt zpatchuje nebo koupí něco co umí KVM. Což.
3.4.2009 17:17
saly | skóre: 22
| blog: odi_et_amo
Kdo mluví o něčem velkém? Já si chci jenom na notebooku pustit jednu, dvě virtuální mašiny na hraní
HAHAHAHHAAAA!!!! Můj ďábelský plán funguje! Pošlu neoptimální kód a nechám ostatní, aby ošklivou práci udělali za mě!!!! Eh, neřekl jsem to náhodou nahlas?
Steven Rostedt
Nejenom že řekl, ale navíc tě zažaluju, protože na tenhle algoritmus mám patent.
Linus Torvalds
Skoro som spadol zo stoličky
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.