Jaderné noviny - 4. 6. 2008

23. 7. 2008 | Jirka Bourek | Jaderné noviny | 3295×

Aktuální verze jádra: 2.6.26-rc4. Citáty týdne: David Miller, Nick Andrew. Interview se správci embedded zařízení. Pokrytí profilovaného jaderného kódu. Odstraňování firmwaru.

Obsah

• Aktuální verze jádra: 2.6.26-rc4
• Citáty týdne: David Miller, Nick Andrew
• Interview se správci embedded zařízení
• Pokrytí profilovaného jaderného kódu
• Odstraňování firmwaru

Aktuální verze jádra: 2.6.26-rc4

Současné vývojové jádro 2.6 je stále 2.6.26-rc4 vydané 26. května. Verze -rc5 by se měla objevit tento týden. Pokud se můžeme řídit historií, vyhlížejte ji těsně poté, co vyjde tento článek.

Citáty týdne: David Miller, Nick Andrew

Tohle mě skutečně irituje, protože je to jeden velký případ Farmy zvířat. Nejdřív nám sebrali málo, potom o něco více a na konci máme něco, s čím by na začátku absolutně nikdo nesouhlasil.

-- David Miller o odstranění firmwaru (čtěte níže)

Pravděpodobně bych také udělal několik gramatických změn. Pokud budete s obsahem spokojeni a váš dokument bude ve stromě, pošlu patch :-)

-- Nick Andrew

Interview se správci embedded zařízení

Linuxu pro embedded zařízení se v těchto dnech dostává hodně pozornosti. Byla založena nová mailová konference linux-embedded - archivována zde - a již jsou do ní zasílány diskuze a patche. Paul Gormake a David Woodhouse se navíc dobrovolně nabídli, že budou pro jádro "správci embedded", aby pomohli koordinovat linuxovou komunitu embedded zařízení. Laskavě souhlasili se spojeným e-mailovým interview, které by vrhlo nějaké světlo na jejich nové role.

LWN: Z čeho pramení vaše zkušenosti s Linuxem, obzvláště s embedded Linuxem?

David: K Linuxu jsem se dostal, když jsem byl na univerzitě a během jedněch letních prázdnin pracoval v Nortelu na projektu pro síťování přes hlavní napájecí vedení. To zahrnovalo linuxové stroje jako routery a já jsem pro ně pracoval na úložných zařízeních bez pohyblivých částí [solid state]. Z toho a ze základní podpory, kterou jsme měli pro podobná zařízení v základech kódu PCMCIA, vyrostl subsystém MTD [Memory Technology Device].

Po nějakém čase jsem skončil u Red Hatu, kde jsem pracoval v oddělení technických služeb [engineering services] na portech desek, ovladačích a na dalším. V té době byl napsán JFFS2 jako část kontraktu se zákazníkem.

V Red Hatu jsem byl od roku 2000 na různých pozicích, většinu z posledních pár let v OLPC. Kvůli špatnému chování ze strany HR jsem v pondělí dal výpověď a půjdu jinam. S novým šéfem jsem mluvil předtím, než jsem se nabídl do pozice 'správce embedded zařízení', a jemu to vyhovovalo - jde o další firmu, která podporuje Linux, kde budu pracovat na vývoji jádra a kde interakce s komunitou zůstane v popisu mé práce.

Paul: Linux jsem začal používat v časech před 1.0 a vždycky jsem byl z těch, kdo rozebírají věci a dívají se, jak fungují. Mít možnost to dělat s operačním systémem mě přitahovalo. Dal jsem dohromady různé dokumenty, které lidem pomáhaly v době, kdy byla potřeba docela vysoká úroveň znalostí, aby mohl člověk začít na Linuxu pracovat. Začal jsem opravovat a psát ovladače a v tom jsem pokračoval. V roce 2005 jsem se přidal k Wind River, kde jsem se zaměřoval hlavně na jádro a patche specifické pro desky, což mi dalo příležitost seznámit se s různými architekturami a spoustou variant desek v každé rodině architektur.

LWN: Jakou úlohu očekáváte od správců embedded zařízení v jádře?

David: Ve skutečnosti spoustu věcí. Není to obvyklá úloha správce, kde bychom přebírali vlastnictví sekce kódu; je to trochu víc pružné.

Pro začátek - jednou z věcí, kterou musíme udělat, je pracovat s různými lidmi, kteří Linux používají v "embedded" situacích, a pomoci jim lépe spolupracovat s komunitou. A nejde jenom o prodejce vybavení pro zákazníky - jde také o komunity, jako jsou ty kolem OpenWRT, handhelds.org, OLPC. V žádné jiné oblasti není vývoj Linuxu rozdělen tak, že spousta lidí má své vlastní patche nebo celé stromy kódu.

Další část naší práce, což je ve skutečnosti něco, co jsem stejně dělal už léta, je revidování změn v jádře obecně s ohledem na to, jak ovlivňují embedded systémy. Nejde jenom o bloatwatch [sledování velkých zbytečností], i když ten je zjevně součástí. Také to pokrývá věci, jako je sledování lidí od IBM zSeries, kteří pod z/VM poskytují pro bloková zařízení podporu pro vykonání na místě [execute-in-place], a kladení otázek "hej, jak bychom mohli použít tu samou správu paměti pro XIP z flash?"

Jednou z dalších částí je implementace takových vlastností ve vnitřním jádře [core kernel], které jsou motivovány "embedded" potřebami. Jde o triky pro kompilaci jádra s -fwhole-program --combine, aby například GCC mohlo lépe optimalizovat a redukovat velikost kódu.

U určité části té práce, obzvláště v konferenci linux-embedded@vger.kernel.org, očekávám, že to bude nějaký druh specializovaného kernelnewbies - zjevně se specifickým zaměřením na záležitosti embedded zařízení a v určitém rozsahu více na profesionální vývojáře než na tak velký podíl lidí, kteří mají jádro jako koníček. Nicméně rozhodně nemám v úmyslu odrazovat nadšence a studenty od toho, aby se zapojili do vývoje. Ostatně, je to dobrý způsob, jak přesvědčit lidi, aby vám poslali hezké hračky!

Chtěl jsem se vyhnout gitovému stromu 'linux-embedded', ale pro malé věci, jako je patch, který do konference linux-embedded zaslal Tim Bird a který zavádí CONFIG_CONSOLE_TRANSLATIONS, to má smysl - takže jsem ho vytvořil na git://git.infradead.org/embedded-2.6.git.

Paul: Je několik věcí, které zde lze udělat a ze kterých bude nakonec mít užitek Linux a jeho uživatelé. Pro začátek doufám, že budeme schopni uzavřít mezeru mezi lidmi, kteří příliš nesledují vývoj jádra, ale přesto se rozhodli pro Linux vyvíjet se specifickým embedded cílem, a lidmi, kteří Linux vyvíjejí už dlouho. Také můžeme zlepšit spojení mezi lidmi, kteří píší změny vlastností, a některými uživateli těchto vlastností, kteří jimi budou postiženi, ale kteří by se pravděpodobně neozvali. Můžeme hledat externě spravované vlastnosti, které by embedded uživatele mohly zajímat, snažit se přijít na to, jaký faktor jim (nebo jejich částem) brání v začlenění do upstreamu, a pomoci při odstraňování těchto bariér tam, kde to bude možné.

LWN: Jakým specifickým problémům čelí embedded vývojáři, kteří se snaží použít Linux? Co můžete udělat pro to, aby se situace zlepšila?

David: Myslím si, že největší a jediný problém byl vždy stejný - jde o to, že lidé se příliš snaží vykopnout své věci ze dveří tak rychle, jak je to jen možné, aniž by přitom přemýšleli o spolupráci s upstreamem. Manažeři nemají v rozpočtu čas na začlenění a inženýři o svém designu nemluví dostatečně brzo, aby mohl být vylepšen předtím, než jde o hotovou věc. Ten čas navíc kvůli začlenění není jenom o tom být dobrým občanem - když to neuděláte, téměř vždycky se vám to vrátí a osobně vás to kousne, když chcete vyrobit nový produkt, aktualizovat produkt nebo i dokonce když potřebujete začlenit změny z upstreamu, které opravují chyby. Zdá se ale, že na tohle všichni musí přijít tím těžkým způsobem.

Paul: Ve spoustě případů se dostáváme do situace, kde se skupina, která vyvíjí pro embedded platformu, stoprocentně zaměřuje na to, aby byl jejich produkt hotov, fungoval a prodával se. Zapojení vývojáři většinou nejsou hard core lidé od Linuxu a co se jich týče, obvykle pouze vyberou verzi jádra, dostanou své věci do lokálního stromu a to je celé. Možná neznají git, možná nemají potuchy o tom, kdo jsou správci subsystémů, možná vnímají LKML jako příliš nepřátelské prostředí nebo jim možná management neplatí za to, aby protlačili své věci do upstreamu. Nevyhnutelně ale uplyne nějaký čas a oni musí dál pokračovat v práci, přičemž je čeká velký skok mezi revizemi všech jejich změn, což se donekonečna opakuje.

Většina lidí, kteří museli podstoupit skok o revizi i průběžné sledování změn, vám řekne, že skok není ten správný způsob, a to z mnoha důvodů. Nicméně se zdá, že to je lekce, kterou každý stejně musí dostat sám. Takže doufám, že některé z těchto lidí přesvědčíme, aby se více přidružili k typickému toku práce v Linuxu, tj. pracovat s nejnovější základnou kódu, vytvářet logické sady změn, které se mohou stát kandidáty na zaslání atd. Nedávno jsem byl na několika setkáních, kde jsme měli příležitost poučit v tomto ohledu embedded vývojáře o výhodách. Zpětná vazba byla doteď pozitivní.

LWN: Velikost jádra obecně roste, nezačíná být pro embedded aplikace příliš velké? A jestli ano, co by mělo být uděláno, aby se situace zlepšila?

David: Je mi jasné, že budou lidé, kteří mě za tohle budou chtít zastřelit, ale myslím si, že velkou částí řešení tohoto problému je vědět, kdy je Linux odpověď, a akceptovat, že občas není. Například jsem vždy trochu pochyboval o implementaci podpory XIP v Linuxu na základě toho, že když má někdo takový zájem, měl by pravděpodobně stejně použít něco jako eCos.

Když se ale vrátím ke skutečné otázce, jsou věci, které můžeme udělat. Menší a efektivnější "slub" paměťový alokátor je jeden příklad, stejně jako --combine, které jsem zmínil na začátku. Trik je v tom najít způsoby, jak záležitosti vylepšit, aniž byste prostě celek zaneřádili ifdefy.

Paul: Vždycky bude nějaký hardware nebo nějaký případ použití, ve kterém Linux není ta správná volba. Samozřejmě má smysl použít pro práci správné nástroje, nicméně se chceme snažit zajistit, že Linux bude ten správný nástroj pro tak mnoho případů, jak to jen bude možné. Na straně výhod je to, že zdroje, které jsou dnes k nalezení na typickém embedded zařízení, jsou mnohem bohatší, než byly před léty. My se jenom potřebujeme ujistit, že optimalizace pro obecný příklad použití - x86 - nedopatřením nezhorší situaci těm více okrajovým případům, které přicházejí z embedded světa.

LWN: Jaké priority vidíte v práci na jádře, aby lépe podporovalo embedded Linux?

David: Právě teď je jednou důležitou prioritou nahrazení JFFS2. Napsal jsem ho, takže to můžu říct - ve své době, kdy byla NOR flash zařízení v řádech 32 MB, byl dobrý. Ale protože jsem musel zařídit, aby pracoval na 1GB NAND flash v OLPC, rozhodně souhlasím, že ho tlačíme za limity jeho návrhu. Velice se těším na to, až bude LogFS a/nebo UBIFS začleněn do jádra a stabilizován tak, abychom na něj mohli skutečně přejít.

Potřebujeme také docela urgentně obnovit MTD API. Když jsme ho dělali, bylo bez velkého plánování odvozeno od PCMCIA kódu a nyní ho skutečně potřebujeme vylepšit.

Řekl bych, že ve věcech, které jsem vybral, může být trochu zaujatosti.

Paul: Embedded komunita jako celek je pravděpodobně největší uživatel ze všech architektur mimo platforem založených na x86. Funkčnost některých věcí mimo základní x86 rodinu není příliš testována. Například jednou z vlastností, o kterou je značný zájem, je kompletní sada patchů preempt_rt. Jenže jakmile se dostanete mimo rodinu x86, máte téměř garantováno, že narazíte na ovladače specifické pro embedded zařízení, které se nechovají moc dobře, když se tato sada patchů použije. Není to takové překvapení prostě proto, že spojení těchto dvou nebylo ještě prozkoumáno. Myslím si, že má cenu prozkoumat tyto typy průniků raději dříve než později zmenšením mezery mezi lidmi, kteří na takovém druhu změn pracují, a lidmi, kteří mají v úmyslu použít je na embedded platformách.

LWN: Máte nějaké specifické cíle ohledně doby, za kterou byste chtěli různé vlastnosti začlenit?

David: Kromě "co nejdřív" u LogFS a UBIFS ne. Věci se začleňují, když jsou připravené.

Paul: V tuto chvíli ne. Nemám zájem přepadnout něčí projekt nebo vlastnost a pokusit se nutit autory k začlenění do nějaké doby, kterou sám určím. Raději bych s nimi spolupracoval a zkusil přijít na to, jaké jsou problémové oblasti. A ať už budou logistické nebo technické, pokusil bych se, pokud to bude možné, pomoci autorům dostat se do bodu, ve kterém budou cítit, že své dílo mohou nabídnout jako kandidáta na začlenění.

LWN: Jaké problémy předvídáte co se týče práce s ostatními jadernými vývojáři, kteří mohou mít menší (nebo žádný) zájem o potřeby embedded komunity? Jsou nějaké specifické vlastnosti, které může být obtížné nebo nemožné začlenit?

David: Vím, že je moderní tvrdit, že mezi uživateli embedded zařízení a velkého železa jsou velké rozdíly, ale ve skutečnosti se tam překrývá víc věcí, než si spousta lidí uvědomuje. Dříve jsem zmínil XIP; uhádnete také, kdo první implementoval podporu pro beztikové [tickless] jádro?

Velká část problému doteď spočívala v tom, že byli lidé, kteří se objevili, hodili po nás svůj kód a pak utekli. Nebo ještě hůře, že po nás ten kód ani nehodili. Zdá se, že lidé zapomněli, jak dlouho nám trvalo vzdělat velké firmy, aby s námi hezky spolupracovaly; v tomto ohledu jsme na embedded straně trochu pozadu, ale doháníme to. A organizace jako CELF na této frontě také dělají dobrou práci.

Paul: Musíme být realističtí. Vždycky budou nějaké vlastnosti, které jsou buď příliš invazivní, aby se daly považovat za rozumné kandidáty na začlenění, nebo které mají tak malou uživatelskou základnu, že z pohledu nákladů nemusí mít smysl snažit se s nimi mířit k začlenění do standardního jádra. Myslím si, že naštěstí komunita vývojářů Linuxu obecně byla téměř vždy flexibilní, co se týče přijetí většiny věcí, stejně jako ve vylučování věcí tam, kde to bylo potřeba udělat v nejlepším zájmu jádra jako celku.

V takových případech, kdy vlastnost nebude vypadat jako pravděpodobný kandidát na začlenění, není nic ztraceno. Stále můžeme vydělat na tom, že s tím budeme pracovat, jako kdyby to kandidát na začlenění byl. Věci jako vybírání třešní [cherry-picking] z takové věci mají obecnou hodnotu a to redukuje udržovací náklady. Také budeme schopni říct v patřičném čase svůj názor, pokud si správce té vlastnosti všimne, že navrhovaná změna někde jinde v jádře postihne vlastnost, kterou spravuje nezávisle. Proto si myslím, že stále chceme pracovat na tom, abychom přesvědčili lidi, kteří se starají o tyto "obtížnější" vlastnosti zajímavé pro embedded komunitu, aby pracovali paralelněji s komunitou kolem hlavní řady.

LWN: Termín "embedded Linux" pokrývá velké spektrum zařízení a využití Linuxu, všechno od zařízení, kde je OS kompletně neviditelný, přes internetové tablety až k UMPC zařízením, což jsou v podstatě desktopy stlačené do menšího balení. Kde v tomto spektru leží vaše zájmy? Kde si myslíte, že vás čekají potíže, když se budete snažit podporovat všechna tato různá využití?

David: Můj zájem leží v celém tomto spektru - i mimo něj. Příliš velké zaměření na jednu malou oblast je způsob, jakým člověk vyřeší své problémy, ale pro ostatní lidi věci zhoršuje. Myslím si, že je důležité udržovat určitou úroveň zaměření se na celek, protože tak můžeme zajistit, že bude Linux dobře škálovat jak nahoru, tak dolů.

Paul: Jednoznačně. Zdá se, že lidé si automaticky spojují embedded s tím malým a na zdroje omezeným koncem škály. Skutečnost je taková, že jsou lidé, kteří chtějí Linux používat v embedded aplikacích, kde má základní hardware 16 jader a gigabyty paměti. Na jednom konci škály vás zajímají věci, jako je efektivita využívání zdrojů a rychlé bootování, a na druhém leží vaše zájmy okolo vlastností, které jsou spojeny s vysokou dostupností a nemusí být přítomné v standardním stromě jádra.

Toto jsou zjevně oddělené oblasti problémů, ale společnou věcí, kterou oba sdílejí, je skupina lidí používající specifický kus hardwaru se specifickým způsobem užití. To potom vede k tendencím přinášet mentalitu "nám to funguje, pojďme to dokončit a prodávat" a ta práce se nikdy nedostane ven, aby si ji mohli prohlédnout ostatní a dívat se po kouscích, jejichž začlenění by mělo smysl. Doufám, že tady budeme schopni něco změnit.

Rádi bychom poděkovali Davidovi a Paulovi za to, že si udělali čas na zodpovězení těchto otázek.

Pokrytí profilovaného jaderného kódu

Měření, které řádky kódu jsou vykonávány a jak často, může být užitečný nástroj pro ladění a testování. Pro programy v uživatelském prostoru to je dlouho možné pomocí gcov. Nedávný patch se snaží umožnit použití tohoto nástroje i jaderným programátorům.

Aby gcov v jádře fungoval, jsou potřeba tři hlavní komponenty: změna překladu přidáním gcc příznaků -fprofile-arcs -ftest-coverage, připojení kódu, který vygeneruje gcc, k ukládání informací o pokrytí, a poskytnutí způsobu, jakým může jádro data předat do uživatelského prostoru. Kconfig volba GCOV_PROFILE určuje, jestli se do překladu gcov zahrne, zatímco GCOV_PROFILE_ALL aktivuje profilování pro celé jádro. Pokud je to požadováno, lze vybrat adresáře a soubory, které budou zahrnuty nebo vyřazeny ze sledování.

Potřebné funkce pro podporu profilovacího kódu, který vygeneruje gcc, jsou obsaženy v adresáři kernel/gcov. Zvládají staticky připojený jaderný kód stejně jako jaderné moduly, které jsou nahrány. Informace nasbírané v modulech mohou být při odstraňování modulu zachovány i smazány. To umožňuje analýzu cesty kódu při odstraňování, což může být užitečné při detekci úniku zdrojů [resource leak] nebo jiných problémů při tomto procesu.

Program kompilovaný v uživatelském prostoru pro gcov zapíše do souborového systému binární soubor pro každý zdrojový soubor; tento binární soubor obsahuje data odpovídající cestě vykonání v příslušném zdrojovém souboru. Jádro to musí dělat jinak, takže místo toho vytvoří soubor v debugfs. Každý zdrojový soubor, který je kompilován pro gcov, své informace uloží do /sys/kernel/debug/gcov/cesta/soubor.gcda, kde /sys/kernel/debug je připojovací bod debugfs a cesta je cesta k souboru v jaderném stromě. Do jednotlivých .gcda souborů lze zapisovat, což vynuluje nasbíraná data pro daný soubor.

Když jsou nasbírána data, lze zavolat gcov, který vygeneruje soubor se zdrojovým kódem, ve kterém jsou ke každému řádku přidány komentáře obsahující údaj o tom, jak často byl řádek vykonán. K prohlížení těchto informací lze také použít nástroj LCOV. Jak LCOV, tak jaderný patch gcov pocházejí z Projektu testování Linuxu, který obsahuje rozsáhlou testovací sadu pro jádro a používá gcov k rozšíření pokrytí svých testů.

Součástí této sady patchů je rozšíření rozhraní seq_file, aby umožňovalo zápis binárních dat do virtuálního souboru. V současnosti je rozhraní seq_file poněkud znakově orientováno, takže do fs/seq_file.c byla přidána funkce:

int seq_write(struct seq_file *seq, const void *data, size_t len)

Jak naznačuje prototyp, zapíše len bytů z data do seq_file seq.

Snahy dostat do jádra podporu pro gcov tu byly přibližně od roku 2002, ale nedávno byl kód přepsán, aby se lépe hodil k současným jádrům. V patchi Peter Oberparleiter říká: Kvůli pravidelným požadavkům jsem přepsal gcov-kernel patch od základu, takže (snad) bude začlenitelný do upstream jádra. Jednou z větších změn je přesunutí rozhraní pro uživatelský prostor z /proc do debugfs.

Zdá se, že technické záležitosti byly v třetí verzi gcov patche vyřešeny. Patch může poskytnout užitečné informace obzvláště rozšířením rozsahu pokrytí testováním - což je něco, co může pomoci redukovat chyby - takže by z toho mohl být hezký přírůstek do jádra. Jestli bude vybrán do linux-next nebo do -mm a protlačen směrem k eventuálnímu začlenění do hlavní řady, se ještě uvidí.

Odstraňování firmwaru

Zdá se, že David Woodhouse měl skrytý motiv, když nedávno přepracoval jaderný zavaděč firmwaru. Tím nemá být řečeno, že ta práce není sama o sobě užitečná, ale jeden z jeho cílů je nyní zjevnější: odstranění veškerého firmwaru z jaderného zdrojového stromu. Tím, že zjednodušil oddělení blobů firmwaru - ale stále umožnil staticky je zabudovat do jádra - poskytl možnou cestu, díky které může veškerý firmware potřebný pro jakýkoliv ovladač pro Linux žít na jednom místě.

Záležitosti okolo firmwaru jsou poněkud problematické, přinášejí licenční a politické diskuze, které jaderné vývojáře většinou obtěžují. Čas od času zaplanou hádky o "legálnosti" distribuování firmwaru s jádrem. Kromě toho existují další důvody, proč má smysl držet firmware odděleně: některé distribuce potřebují nebo chtějí distribuovat svá jádra bez blobů firmwaru a někteří výrobci hardwaru neumožňují distribuovat svůj firmware s jádrem kvůli obavám z GPL. Současná situace ztěžuje život jak uživatelům, tak distributorům.

David přednesl nápad na vytažení firmwarů z jádra v příspěvku do linux-kernel a ksummit-2008-discuss. Agenda pro letošní Kernel Summit se diskutuje, takže navrhl, aby se to vyřešilo tam. Zjevně se také snaží předpokládat technické záležitosti, které mohou ostatní znepokojovat:

V době, kdy bude kernel summit, bychom za sebou měli mít slušný pokrok v přesouvání všech firmwarů do adresáře firmware/. V tomto bodě bych je rád zcela odstranil do odděleného gitového stromu a tarballu. Ti, kteří je budou chtít zabudovat do svého statického jádra, to stále budou moci udělat, ale nebude to výchozí chování.

Není překvapivé, že jsou poměrně značné námitky. David Miller je poněkud otráven:

Sorry, ale tím se věci dostávají moc daleko. Bojoval jsem přibližně... stále, abych udržel ovladač tg3 s jeho firmwarem ve stromě. Odmítám nechat tento ovladač takhle rozbít, bude fungovat dál a to znamená firmware ve stromě a připojen do ovladače.

Jestliže má Debian nebo kdokoliv jiný tyto obavy a chce firmware vytrhnout, je to na sto procent jejich problém a můžou věci vypatchovat z jader, které používají.

Jsou ale další důvody, proč shromažďovat firmwary na jednom místě, jak poznamenává Arjan van de Ven:

Právě teď je pro uživatele královský problém v tom, aby sehnali všechny kousky firmwaru... kdybychom měli JEDNO místo, kam dali všechny, hodně bychom se posunuli směrem k tomu, aby byly věci jednodušší.

Jestliže se chceš hádat, že to místo by měl být jaderný tarball sám o sobě, ode mě neuslyšíš žádné námitky. Ale od ostatních jo... a proto by druhý tarball mohl být odpovědí. Hlavně když nebudeme potřebovat 100 tarballů.

Nicméně se ještě objevily velké obavy, že přiložení firmwaru bez zdrojového kódu do jádra by bylo porušení GPL. Je nemožné to říct bez rozhodnutí soudu, což je něco, s čím nikdo nechce nic mít. Firmy - a jejich právníci - mají tendence být velmi konzervativní co se týče přivolávání soudních procesů, takže odstranění zbytečného kódu, který může být žalovatelný, z jejich zdrojového kódu jim přinese velké výhody. Jak řekl David:

A nejedná se jenom o šílence. Fedora chce také distribuovat firmware v balení odděleném od jádra -- kvůli tomu, že to údajné porušení GPL je tak zbytečné riziko vzhledem k tomu, že stejně vždycky používáme initrd a protože lidé chtějí být schopni vytvořit 'Svobodné' verze, které firmware vůbec neobsahují ani ve zdrojových balíčcích.

To, že se zjednoduší vložení všech firmwarů do jednoho ne-GPL stromu, může přesvědčit prodejce hardwaru - a jejich právníky, aby umožnili firmware distribuovat. Jestliže bude Davidův plán pro podporu nahrávání firmwaru jak v době překladu, tak v době běhu úspěšný a dostatečně průhledný, pro jaderné vývojáře to bude znamenat minimální rozdíly, ale přinese to velké zlepšení pro uživatele a distributory. Není jasné, jestli je to téma, které bude vyřešeno e-mailem, jak doufá David, nebo jestli to bude v září vyžadovat diskuzi na Kernel Summitu, ale je to nápad, který obsahuje tolik výhod, že si časem může najít svou cestu do hlavní řady.

       

Komentáře

[bk]

V tom rozhovoru to neni Paul Gormake, ale Paul Gortmaker...