11.11.2008 10:47
Pavel Půlpán | skóre: 22
| Trutnov
Rozbalit Rozbalit vše Re: Jaderné noviny - 1. 10. 2008
Portál AbcLinuxu, 6. května 2025 00:19
Aktuální verze jádra: 2.6.27-rc8. Citáty týdne: Alan Cox, Linus Torvalds, Roland McGrath. Stav chyby v e1000e. Nízkoúrovňová sledovací instalatéřina. Stěhování stromu -staging.
Tento článek je překladem z anglického originálu, a proto vychází se zpožděním.
Současné vývojové jádro 2.6 je 2.6.27-rc8, které Linus vydal 29. září. Říká, že je to pravděpodobně poslední -rc před finální verzí 2.6.27, ale není jisté, jestli v tu chvíli myslel na problém s e1000e (vizte níže).
Do repozitáře hlavní řady dorazila od vydání 2.6.27-rc8 hrstka patchů.
Během minulého týdne nebyly vydány žádné stabilní verze 2.6; nejnovější stabilní vydání 2.6.26.5 pochází z 8. září.
API pro uživatelský prostor, které navrhuješ, by však mělo být vyvedeno a zastřeleno, poté pohřbeno s kolíkem v srdci, svěcenou vodou v ústech a useknutou hlavou, o půlnoci, v pentagramu na křižovatce a za přítomnosti kněze.
-- Alan Cox, který se podivně hodí do role kněze.
Mimochodem, skutečná chyba je zjevně v návrhu hardwaru, který umožňuje nechat se zlikvidovat, aniž by měl aspoň zamykací bit.
Doufám, že to Intel nebude považovat za čistě softwarovou chybu. Nějaký návrhář hardwaru by měl hodně přemýšlet, do jakého otvoru strčí hlavu.
To byl laciný, pitomý, smrkáčský manévr. Škoda, že nepiju, protože jinak by si dnes večer někteří jaderní hackeři v baru vyslechli svůj díl čerstvých pověstí o inteligenci programátorů stapu [SystemTap]. Ok, staprune, momentík, dojdu si pro hadřík na prdelku a zachovám se jako správný rodič.
-- Roland McGrath si užívá se SystemTapem.
Program má také uživatelské rozhraní, které mohou děti spustit, aby viděly, kolik času jim zbývá, takže vyhození od počítače pro ně nebude úplné překvapení. A včera se Patricia zeptala, proč je tak ošklivé. Musel jsem se přiznat, že její tatínek prostě uživatelské rozhraní moc neumí...
-- Linus Torvalds neumí ohromit své děti (díky Nicolasi Pitreovi).
Linus Torvalds 29. září vydal 2.6.27-rc8 s tímto komentářem:
Toto -rc by mělo být poslední: rozhodně nám nedošly regrese, ale na druhou stranu musím vybrat nějaký okamžik a regrese jako celek nevypadají příliš děsivě.
Toto tvrzení vyvolalo vrásky u lidí, kteří nervózně sledují hardware poškozující chybu s e1000e. I když se komunita vývojářů na lecjakých záležitostech neshodne, je zde rozumně silný konsenzus, že chyby ničící hardware lze považovat za "děsivé".
Vzhledem k tomu by bylo hezké říci, že tato konkrétní regrese byla dohledána a opravena, ale není tomu tak. V době psaní tohoto článku nikdo neví, co způsobuje, že v systémech s jádry 2.6.27-rc občas dojde k přepsání EEPROM u síťových adaptérů e1000e (v době vydání tohoto článku je již k dispozici dočasná oprava od Intelu). Pokrok, kterého bylo dosaženo, problém trochu zužuje:
Zpočátku se objevila hypotéza, že za problém může být zodpovědný kód grafického správce paměti GEM. Objevily se nicméně hlášení o poškození u distribucí, které GEM nebalíčkují, takže GEM již není podezřelý.
Z podobných důvodů byl zavržen nápad, že za to nějak může práce na tabulce atributů stránek [page attribute table, PAT].
Byla silná korelace mezi poškozením hardwaru a přítomností grafického hardwaru od Intelu. To vedlo k mnoha spekulacím, že poškození může nějak vyvolat Intel ovladač pro X.org, přičemž oddělená chyba v ovladači e1000e umožňuje, aby se to stalo. Nyní ale bylo nahlášeno poškození v systému, který měl grafiku NVIDIA. Pokud se toto hlášení opravdu týká stejného problému, pak bude hypotéza o X.org podstatně oslabena. (Jen tak mimochodem by stálo za to zamyslet se nad tím, co by se stalo, kdyby problém jako první nahlásili uživatelé NVIDIA; pokušení obvinit proprietární ovladač NVIDIA by mohlo být dost silné na to, aby se po nějaký čas odkládalo hledání chyby.)
Příznaky ukazují na problém lokalizovaný v ovladači e1000e, ale je příliš brzy považovat to za závěr. Tato chyba je stále záhadná a nakonec se může ukázat, že má překvapující příčiny.
Kvůli povaze této chyby je vysledování obtížnější než obvykle. Zdá se, že závisí na nějakém souběhu, takže je obtížné ji reprodukovat. Způsob, jakým se projevuje, má za následek velké omezení počtu testerů, kteří by se ji vůbec reprodukovat snažili. Lidé, kteří se dané kombinaci softwaru mohou vyhnout, to dělají a distributoři dodávající vývojová jádra, zakázali ovladač e1000e. Přístup Dava Airlieho: Nechávám to ale na Intelu, nemyslím si, že by se HP líbilo, kdybych jim neustále vracel svůj laptop, je určitě velmi typický.
Vypadá to, že pod mnoha pozadími v Intelu byl zažehnut poměrně silný oheň; jeho vývojáři jsou aktivní v diskuzích a zjevně chtějí, aby byl tento bug vyřešen. Jedním z cílů bylo vytvoření nástroje, který by vrátil hardware do funkčního stavu, ale jeho příchod je pomalý. Obnovení rozbitých adaptérů e1000e je, zdá se, složitý problém - ale takový, který Intel musí vyřešit. Jestliže chceme podpořit více testerů, aby riskovali poškození s tím, že je k dispozici nástroj, který jejich karty zase obnoví, tak ten nástroj musí v tu chvíli skutečně existovat. Těžko Intelu vyčítat, že si dává načas, aby zajistil, že bude nástroj skutečně fungovat; jeho nepřítomnost ale mezitím ztěžuje testování.
Frans Pop položil otázku ohledně dlouhodobých problémů: i když bude tato chyba zítra opravena, ve většině historie 2.6.27 bude přítomna. Každý, kdo bude jádro dělit půlením ve snaze vysledovat jakoukoliv jinou chybu, riskuje, že ho pokouše zombie verze chyby v e1000e. Pravděpodobně nebude jiný způsob, jak se tomuto nebezpečí vyhnout, než vydat nějaká velká varování. Odstranit chybu z repozitáře hlavní řady přepsáním jeho historie je v gitu možné, ale vytvořilo by to problémy každému, kdo pracuje s klonem tohoto repozitáře.
Mezitím mohou být zajímavé důsledky toho, jestliže vyřešení problému zabere mnohem víc času. Je těžké si představit, že by šlo jádro 2.6.27 vydat s regresí tohoto rozsahu; řekněme, že reakce mainstreamového tisku by nebyla přívětivá. Zpoždění 2.6.27 by mohlo vynutit zpožděné vydání mnoha distribucí. Takové kaskádovité zpoždění by nevypadalo dobře; připomínalo by problémy, se kterými se lze setkat u některých proprietárních softwarových firem.
Ve shrnutí - systém zjevně funguje. Testeři problém odhalili předtím, než byl kód vydán v čemkoliv, co by připomínalo stabilní verzi. Vývojáři se nyní za chybou ženou tak rychle, jak jen mohou. Nebudou žádná vydání stabilního jádra či nové verze distribucí, které by poškozovaly hardware. Tato situace je nepříjemná, ale brzy bude vyřešena a zapomenuta.
Sledování v jádře i uživatelském prostoru bylo hodně diskutováno jak na Jaderném summitu, tak na Konferenci linuxových instalatérů. Účastníci se ale po těchto diskuzích nevytasili s žádnou srozumitelnou vizí toho, jak bude problém sledování vyřešen; v současnosti o tom ještě neexistuje konsenzus. Vzešla z ní ale jedna jasná zpráva: možná skončíme s několika různými sledovacími mechanismy v jádře, ale nebudou trpěny redundantní implementace nízkoúrovňového sledovacího bufferu. Všechny potenciální sledovací frameworky budou muset najít způsob, jak žít s jedním mechanismem, který bude sbírat sledovaná data a předávat je do uživatelského prostoru.
Tento závěr může vypadat jako způsob, jak odvrátit pozornost od nepříjemných problémů na vyšších úrovních a místo toho zaměřit pozornost všech na záležitosti tak nízkoúrovňové, že skutečné problémy zmizí. Může na tom být něco pravdy. Je nicméně také pravdou, že nikdo nevolá po duplikování stejných funkcí různými sledovacími frameworky; přijít se společným řešením této části problému může dlouhodobě vést jenom k lepšímu jádru. Je zde ale další cíl, který je stejně tak důležitý: donutit všechny sledovací frameworky používat jediný buffer jim umožní, aby pracovaly naráz. Není těžké si v budoucnu představit sledovací nástroj, který by integroval informace sbírané zároveň ftrace, LTTng, SystemTapem a dalšími sledovacími nástroji, které ještě nebyly napsány. Donutit tyto nástroje používat stejnou nízkoúrovňovou instalatéřinu by tuto integraci mělo zjednodušit.
S tímto cílem se Steven Rostedt rozhodl vytvořit nový, sjednocený sledovací buffer; v době psaní tohoto článku se patch již připravoval na svou desátou iteraci. Zběžné pročtení patche by mohlo čtenáře zmást; 2000 řádek relativně komplexního kódu, který implementuje něco, z čeho se nakonec vyklube pouhý kruhový buffer. Tento kruhový buffer dokonce ještě není vhodný pro použití sledovacími frameworky; kvůli tomu je potřeba přidat oddělenou "sledovací" vrstvu. Klíčovým bodem je zde to, že u sledovacího kódu je kriticky důležitá efektivita. Jedním z hlavních případů nasazení sledování je situace, kdy je potřeba ladit problémy s výkonností ve velmi zatížených produkčních prostředích. Těžkotonážní sledovací mechanismus by vytvořil efekt pozorovatele [observer effect], který může zamlžit situaci, jež vyžadovala sledování, narušit chod produkčního nasazení systému nebo obojí. Aby byl přijatelný, musí mít sledovací framework nejmenší možný dopad na systém.
Patch sjednoceného sledovacího bufferu používá snad každý známý trik, jak omezit náklady na svůj běh. Kruhový buffer je ve skutečnosti sada bufferů pro každé CPU, z nichž každý umožňuje bezzámkové přidávání a spotřebování událostí. Formát události je vysoce kompaktní a všude je velká snaha vyhnout se jeho kopírování. Místo udržování oddělené struktury, která by sledovala obsah jednotlivé stránky v bufferu, patch využívá další přetíženou [overloaded] variantu struct page v paměťové mapě systému. (Autor tohoto článku by nechtěl být v kůži dalších vývojářů - nešťastníků, kteří musí modifikovat struct page a během toho vysledovat a opravit všechna ta ošidná ve-skutečnosti-nikoliv-použití-struct-page v jádře). A tak dál.
Patch sám o sobě docela slušně popisuje API sledovacího bufferu; tato diskuze zde nebude opakována. Stojí nicméně za to se v rychlosti podívat na nízkoúrovňový formát události:
struct ring_buffer_event {
u32 type:2, len:3, time_delta:27;
u32 array[];
};
Tento formát byl navržen se snahou udržet režii spojenou s každou událostí tak malou, jak je to možné, proto je v něm jediné 32bitové slovo hlavičkových informací. type je zde typem události, len je její délka (kromě případu, kdy není, vizte níže), time_delta je hodnota časového posunutí [offset] a array obsahuje data události.
Jsou čtyři typy událostí: jednou z nich (RINGBUF_TYPE_PADDING) je způsob, jak vyplnit prázdný prostor na konci stránky. Normální události generované sledovacím systémem (RINGBUF_TYPE_DATA) mají délku udávanou polem len, které je posunuto o dva bity doprava. Maximální délka události je tedy 28 bytů (32 bytů mínus čtyři pro hlavičku), což není mnoho. Pro delší události je len nastaveno na nulu a skutečnou délku udává první slovo v poli array.
Další dva typy událostí se týkají časových značek. Během diskuze se ukázalo, že ze dvou důvodů je pro všechny události nutné časování s vysokým rozlišením. Ukládání událostí v polích pro každé CPU, které je nutné pro výkonnost, má za důsledek oddělení událostí, které jsou časově spjaty; přidání precizního sledování času umožní srovnat události do správného pořadí. Rovnání může být řešeno nějakým druhem sériového čítače, ale některým problémům s výkonností lze porozumět pouze blízkým pohledem na přesné časování specifických událostí. Události tedy potřebují data v reálném čase s nejvyšším rozlišením, jaké je praktické.
Jak budou tato data ukládána, stále není jasné a možná to nakonec bude záviset na architektuře. Některé systémy mohou používat přímo data čítače časové značky, zatímco jiné mohou být schopny poskytnout skutečný čas v nanosekundách. Ať bude použit jakýkoliv formát, bezpochyby bude potřebovat 64bitové ukládání. Po většinu času ale budou data mezi každými dvěma událostmi redundantní, takže není žádoucí ke každé události v proudu přidávat celou 64bitovou značku. Kompromisem, kterého bylo dosaženo, je uložit čas, který uplyne mezi jednou událostí a událostí následující, pročež bylo vyhrazeno 27 bitů. Kdyby byl rozdíl časů příliš velký a do daného prostoru se nevešel, kód sledovacího bufferu vloží umělou událost (typu RINGBUF_TYPE_TIME_EXTENT), která poskytne potřebný úložný prostor.
Poslední typ událostí (RINGBUF_TYPE_TIME_STAMP) "bude uchovávat data, aby pomohl udržovat časové značky bufferů synchronní". Tato funkce však ještě nebyla implementována.
Tempo změn kódu sledovacích bufferů se, zdá se, poněkud zpomaluje, jak jsou řešeny komentáře z různých směrů; kód se pravděpodobně blíží ke své konečné podobě. Potom dojde na implementaci protokolů na vyšší úrovni nad ním. Mezitím může pozorný čtenář položit otázku: a co relayfs? Předávací [relay] kód byl v jádře léta a byl zamýšlen k tomu, aby vyřešil přesně tento druh problému.
Pravděpodobně nejpřímější (i když ne nejdiplomatičtější) odpověď na tuto otázku přišla od Petera Zijlstry:
Chlape, relayfs je tak blbě chovající se bordel, že rozšiřovat ho by byl špatný nápad. Lepší je napsat něco nového a smazat všechno, co je s relayfs spojené.
Smazání relayfs by nebylo tak těžké; v současnosti je jenom pár uživatelů. Vývojář relayfs Tom Zanussi ale není přesvědčen, že jsou problémy s relayfs tak vážné, aby to ospravedlnilo jeho vyhození a nový začátek. Zaslal sérii patchů, které pročišťují API relayfs a řeší některé z jeho problémů s výkonností. V tuto chvíli nicméně není jasné, jestli se na tu práci někdo podíval; nebylo k ní mnoho komentářů.
Tak jako tak se zdá, že jádro bude mít brzy nízkoúrovňovou implementaci bufferů. Tím již zbývá jenom vyřešit pár malých problémů, jako je zprovoznit dynamické sledování, osadit jádro statickými sledovacími body, implementovat sledování v uživatelském prostoru atd. Vyřešit tyto záležitosti pravděpodobně zabere nějaký čas a pravděpodobně vyústí v několik různých sledovacích metod zaměřených na různé potřeby. Budeme ale mít nízkoúrovňovou instalatéřinu a to je začátek.
Greg Kroah-Hartman byl na letošním Jaderném summitu označen za "správce šmejdu" za to, že chce dovést ovladače nízké kvality do jádra. Tomuto označení se nevyhýbal, když oznamoval sadu patchů, která by některé z těchto ovladačů začlenila. Ve skutečnosti ho dokonce rozvedl: součástí tohoto patche je zavedení příznaku
Probíhají spory mezi těmi, kdo chtějí ovladače začlenit tak rychle, jak je to možné, a těmi, kdo chtějí, aby dosáhly úrovně kvality jádra nebo se jí alespoň blížily. Greg v červnu založil strom -staging, aby zviditelnil a tím zajistil testování a opravy chyb ovladačům mimo strom. Protože se ovladače v tomto stromě postupně zlepšovaly - do bodu, kdy byly některé převzaty do hlavní řady - věří se, že přesunutí samotného -staging do hlavní řady by postup ještě zrychlilo.
Proto Greg pro tyto ovladače zavedl nový adresář (drivers/staging) a mechanismus, který automaticky nastaví příznak poskvrnění jádra, když je některý z nich načten. To bude uživatele varovat, když modul nahraje - alespoň pokud se podívá do logu - a zahrne tuto informaci do jakéhokoliv oops hlášení, které jádro vyprodukuje. Jaderní hackeři potom mohou odfiltrovat problémy podle toho, o jaké poskvrnění jde - problémy s jádry s načtenými binárními ovladači bývají obvykle aktivně ignorovány.
Začlenění těchto ovladačů do hlavní řady značně zjednoduší život lidem, kteří je budou chtít testovat. Kromě toho budou jejich pročištění a opravy přicházet jako patche pro hlavní řadu, čímž budou zviditelněni vývojáři, kteří na nich pracují. Změna by měla minimální dopad na další uživatele a vývojáře jádra. Konkrétně se jimi vývojáři nebudou muset zabývat v případě změn API, protože aktuální je bude udržovat Greg.
Hlavní stížností na tento návrh bylo to, že duplikuje funkci či záměr příznaku EXPERIMENTAL. Navíc se objevily hlasy, že poskvrnění jádra je zbytečně přísné, nicméně jak Greg zdůraznil: Nic to nestojí a jestliže vývojář nechce ladit jádro, ve kterém je takový ovladač nahrán, toto mu to umožní.
Součástí tohoto diskuzního vlákna je vysvětlení od Paula Mundta, proč nemá EXPERIMENTAL v dnešních jádrech smysl:
EXPERIMENTAL je dneska zbytečné. V praxi to většinou znamená, že něco potřebuje více testování, chce mít někdo možnost vytáhnout z rukávu kartu EXPERIMENTAL, když někdo jiný povolí danou volbu a jádro vybuchne, že volba/vlastnost není v jádře příliš dlouho nebo že byl někdo prostě příliš líný a příznak neodstranil (poslední možnost, dnes pravděpodobně pokrývá 90 % případů ve stromě). Záležitosti, které jsou aktivně rozbité (případy, kdy jádro vybuchne, nepřeloží se atd.) jsou většinou vhozeny pod BROKEN.
Paul pokračuje výčtem výchozích konfigurací, z nichž téměř všechny povolují CONFIG_EXPERIMENTAL, čímž ještě více snižují jeho smysl. Bylo by hezké provést audit všech těchto použití a obnovit smysl tohoto příznaku, ale to je mimo rozsah toho, co se rozhodl udělat Greg. Dokonce i kdyby EXPERIMENTAL měl smysl, stále by tu byl rozdíl. Paul pokračuje:
Dalším klíčovým rozdílem je, že i s experimentálními záležitostmi v jádře se vám dostane podpory, takže to není skutečně poskvrňující přečin. Věci ve staging/ na druhou stranu, i když potenciálně nejsou aktivně nepřátelské vůči zbytku systému, jsou stále neznámou a tudíž jediná bezpečná věc, kterou lze udělat, je poskvrnit systém a umožnit jednotlivým vývojářům rozhodnout se, jestli má cenu dívat se na výsledné oopsy, nebo ne.
Stále jsou tací, kteří mají obavy ze začleňování kódu o nižší než jaderné kvalitě. Randy Dunlap to řekl takto: Myslím si, že máme dost problémů s kvalitou i bez přidávání šmejdu. Linus Torvalds byl ale vždy na straně tábora "začlenit brzy", takže je pravděpodobné, že návrh projde do 2.6.28. Krom toho, jak poznamenal Stefan Richter:
Na druhou stranu většina, pokud ne všechny, ovladače ze -staging jsou ty, které se již používají. Jejich uživatelé se již potýkají s jakýmkoliv problémem, který tyto ovladače mají, a navíc musí bojovat s instalací, což je pro ovladače mimo strom typické.
V poměrně krátkém čase se začleňování ovladačů do hlavní řady značně zjednodušilo. Jednu dobu museli vývojáři pracovat na ovladači po několik vývojových cyklů předtím, než se dostal na takovou úroveň kvality, aby mohl být začleněn. Strom -staging prozatím věci zjednodušuje a zviditelňuje pro testery a vývojáře; tato viditelnost opět podstatně vzroste.
11.11.2008 10:47
Pavel Půlpán | skóre: 22
| Trutnov
API pro uživatelský prostor, které navrhuješ, by však mělo být vyvedeno a zastřeleno, poté pohřbeno s kolíkem v srdci, svěcenou vodou v ústech a useknutou hlavou, o půlnoci, v pentagramu na křižovatce a za přítomnosti kněze.
11.11.2008 15:27
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
"Some hw designer should be thinking hard about which orifice they put their head up in."Nejaky hw designer by sa mal vazne porozmyslat do ktorého otvoru strcili hlavu.
Ono je to těžké, protože doslovné překlady s respektováním všech časů většinou fungujou jenom v učebnicích. Kantoři samozřejmě logicky vyžadují "přesné" překlady, jenomže v praxi se obvykle překládá kontextově (tj., předkladatel zkouší odhadnout, co "nám chtěl básník říct").
Překlad "...by měl hodně přemýšlet, do jakého otvoru strčí hlavu" je samozřejmě špatně - zejména proto, že v češtině ta věta vlastně nedává smysl, slovíčka neslovíčka, gramatika negramatika.
Bohužel ta Linusova věta nezakládá žádnou svou přesnou interpretaci, takže se můžeme jen domýšlet, co chtěl vlastně Linus říct (a počítat s tím, že není rozený english-speaker, takže to klidně může mít blbě). Ono "put st. up in" je velmi nevyjasněné, stejně jako orifice v tomto kontextu.
Osobně bych to přeložil "...by měl hodně přemýšlet, do jaké prdele to vlezl" nebo "v jaké řiti se ocitnul" - samozřejmě, plus dalších 35 formulací s vynecháním anusu v závislosti na publiku. Ovšem, ani toto není překlad, za kterým bych "stál jako skála". To je prostě moje interpretace významové a emocionální roviny, o níž si myslím, že se Linus zrovna pohyboval.
Tak či tak, překladatelé tohoto seriálu odvádějí záslužnou práci a podobná šťourání v hovnech, jaká jsem právě předvedl, považuju za neférová 
.
11.11.2008 21:13
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Ono "put st. up in" je velmi nevyjasněné, stejně jako orifice v tomto kontextu.Nevím, co vám na tom připadá nevyjasněné, už jen z kontextu je to právě jasné
Vaše překlady mají význam jiný než originál - to první naznačuje, že někomu leze do zadku, a to druhé, že má nějaký problém.
Původní překlad jsem opravil na čas minulý.
11.11.2008 22:02
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
). Ani nevím, že bys s mými úpravami měl špatné zkušenosti (zrovna minule mi Robert přitakal).
zejména proto, že v češtině ta věta vlastně nedává smysl, slovíčka neslovíčka, gramatika negramatika.Jaktože ne? Slyšel jsi někdy o pštrosovi?
12.11.2008 00:03
Marek Bernát | skóre: 17
| blog: Arcadia
hardware poškozující chybu s e1000e= "hardware, ktorý poškodzuje chybu?" -- nikdy som nemal rád hardvér...
12.11.2008 14:40
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Ta chyba s e1000e poodkrývá více věcí, než by jeden čekal. Obzvláště je zajimavá ta úvaha, jestli pozdržet vydání jádra, nebo to vydat i se známou chybou. Není mi jasné čeho tím chce Linus docílit. Jestli přenést odpovědnost na distributory (tady máte jádro, ale je tam chyba, tak zvažte jeho vydání), nebo na Intel (naše běžné jádro ničí váš HW). Ani jedno se mi nelíbí. Nevím, jak to dopadlo ve finální versi 2.6.27, ale takto by to probíhat nemělo (podle mě se mělo s vydáním počkat na opravu chyby).To je pěkné - moc o tom nevím, ale zvolený postup je špatný. Finální jádro bylo vydáno sice s chybou, ale bylo zabráněno v tom, aby se projevila.
Není mi jasné čeho tím chce Linus docílit.Mám za to, že Linus je tvrdý pragmatik, ako vždy. Záležitosť z e1000e je len jedna z mnohých, ktore sa jadra 2.6.27 týkajú. A Linus jednoducho nechce blokovať dodanie všetkých ostatných noviniek kvôli tejto jednej.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.