Jaderné noviny – 10. 5. 2012: Zaměřeno na ARM

28. 5. 2012 | Luboš Doležel | Jaderné noviny | 3464×

Aktuální verze jádra: 3.4-rc6. Citáty týdne: Linus Torvalds, Thomas Gleixner, Jon Masters. Podporování multiplatformních jader pro ARM. Statistika vývojového cyklu verze 3.4; Rychlý pohled na ARM.

Obsah

• Aktuální verze jádra: 3.4-rc6
• Citáty týdne: Linus Torvalds, Thomas Gleixner, Jon Masters
• Podporování multiplatformních jader pro ARM
• Statistika vývojového cyklu verze 3.4
  • Rychlý pohled na ARM

Aktuální verze jádra: 3.4-rc6

Aktuální vývojová verze jádra je 3.4-rc6 vydaná 6. května. Další týden a další -rc; myslím, že se blížíme ke konečné verzi. Tudíž prosím o testování.

Stabilní aktualizace: verze 3.0.31 a 3.3.5 vyšly 7. května s obvyklou kupou důležitých oprav.

Aktualizace 3.2.17 se 167 opravami se nyní reviduje a její vydání se dá očekávat 11. května nebo později.

Citáty týdne: Linus Torvalds, Thomas Gleixner, Jon Masters

Takže [KERNEL_CONT] je jako defibrilátor: je dobré ho *mít*, ale je opravdu špatné muset ho *použít*.

-- Linus Torvalds

Mám opravdu rád pohádky, ale ne když jde o jaderný kód.

-- Thomas Gleixner

Honem! Všichni rychle řekněte něco šíleného pro Citáty týdne v dalších Jaderných novinách!

-- Jon Masters (pozor: výsledky jsou zklamáním)

Podporování multiplatformních jader pro ARM

Rozmanitost architektury ARM je jednou z jejích největších předností: výrobci dokázali vytvořit širokou škálu zajímavých zařízení typu system-on-chip nad běžným procesorem ARM. Jenže tato rozmanitost v kombinaci s omezenými možnostmi detekce hardwaru způsobují, že je těžké ARM v jádře podporovat. Aktuálně je nutné pro každý konkrétní systém vytvářet speciální jádro. U většiny jiných architektur je možné podporovat většinu nebo všechny systémy pomocí jediného binárního jádra (nebo možná pomocí dvou, jednoho 32bitového a jednoho 64bitového). Ve světě ARMu nic jako jediné binární jádro, které běží všude, neexistuje. Na zlepšení situace se pracuje, ale v průběhu prací je třeba dělat zajímavá rozhodnutí.

Na systému x86 je jádro z drtivé většiny schopné bootovat a dotazovat se hardwaru, aby zaslal svůj vlastní popis; jádra se tedy dokážou sama konfigurovat pro konkrétní systém, na jakém běží. Ve světě ARMu hardware obvykle takové schopnosti nemá, takže je proto jádru nutné říci, jaká zařízení jsou přítomna a kde je možné je najít. Obvykle tato konfigurace byla uložena v tzv. "board files" [soubory s definicemi pro konkrétní typ desky], která plní řadu úkolů:

• Definice funkcí a kódu pro nastavení daného systému.
• Vytvoření popisu dostupných periferií, obvykle pomocí definice řady platformních zařízení.
• Vytvoření speciální struktury pro popis stroje, která zahrnuje magické číslo definované pro konkrétní systém. Toto číslo je třeba předat jádru přes zavaděč; jádro jej používá pro nalezení odpovídajícího popisu.

Ve stromu pro architekturu ARM jsou aktuálně stovky těchto board files; neznámé množství takových souborů se nachází přímo na zařízeních a ty se do jádra nikdy nedostaly. V rámci typu platformy (konkrétní řada system-on-chip daného výrobce) je často možné umístit vícero board files do jediného jádra s tím, že konkrétní typ stroje se určuje při bootu. Ale kombinování board files napříč různými typy platforem obecně možné není.

Jedním z cílů současného pracovního zápalu ve stromu pro ARM je umožnit tvorbu multiplatformních jader. Důležitým krokem v tomto směru je pokud možno zbavit se board files; ty jsou nahrazovány pomocí stromů zařízení. Board file je nakonec jen převážně statická datová struktura popisující topologii systému; tato datová struktura se může nacházet v textovém souboru předávaném jádru přes zavaděč. Přesunutím nastavení hardwaru z jádra umožňí vývojáři ARMu použití jádra na širší řadě hardwaru. Než se dopracujeme ke skutečné multiplatformní podpoře, tak se toho bude muset ještě hodně udělat - například jde o práci na náležité abstrakci přerušení a hodin - strom zařízení ale představuje důležitý krok.

Arnd Bergmann se nedávno ostatních vývojářů zeptal, jestli má smysl v multiplatformních jádrech podporovat staré (legacy) board files. Nebo jestli by bylo lepší omezit podporu jen na systémy, které používají stromy zařízení pro enumeraci hardwaru. Arnd dal jasně najevo, jaký názor má on sám:

Můj názor je ten, že bychom u multiplatformních jader měli vyžadovat boot se stromem zařízení, protože to značně omezuje kombinatorický prostor při kompilaci, vyhýbáme se tak spoustě starých board files, které stejně nemůžeme otestovat, omezíme tím velikost jádra a budeme tak lidi motivovat k tomu, aby začali používat stromy zařízení u existujícího hardwaru.

Proti tomuto nápadu se postavilo až překvapivě hodně lidí. Někteří vývojáři to zjevně pochopili tak, že Arnd chce zahodit podporu systémů, které nemají podporu stromů zařízení, ale o to tu vůbec nejde. Současná sestavení pro jedinou platformu budou fungovat jako doposud; nikdo s tím nic dělat nebude. Smyslem je ale ulehčit život vývojářům, kteří chtějí rozchodit multiplatformní sestavení; multiplatformní jádra na ARMu nikdy nefungovala, takže vyloučení některých systémů jejich uživatele určitě neošidí o něco, co už v minulosti měli.

Někteří lidé to vnímali jako nahodilé omezení bez technického odůvodnění. Nic nestojí v cestě zahrnutí systémů bez stromu zařízení v multiplatformním jádře, až na dodatečnou složitost a balast, který je s tím spojen. Jenže složitost a balast jsou technické problémy, zejména když je řešený problém už tak sám o sobě dost složitý. Bylo rovněž poukázáno na to, že tu máme starší platformy, které nikdo v poslední době moc neudržuje, ale jsou i tak nadále užitečné pro uživatele.

Nakonec půjde hlavně o to, co budou uživatelé multiplatformních jader chtít. Nebylo hned zrovna jasné, že si taková jádra najdou své uživatele: jádra pro ARM jsou obvykle zacílena na konkrétní zařízení, takže přidání podpory pro jiné systémy nemá žádné výhody. Proto výrobci embedded systémů asi nebudou mít o multiplatformní jádra zájem. U distributorů je to ale něco trochu jiného; rádi by podporovali spoustu hardwaru bez nutnosti sestavovat velké množství jader. Vývojář Debianu Wookey to popsal takto:

Rádi bychom viděli multiplatformní jádra, protože muset jich sestavovat obrovskou hromadu je dost nepříjemné (a nejen pro arm, protože to zdržuje bezpečnostní aktualizace) a pokud bychom to mohli pokrýt jediným jádrem, nebo samozřejmě méně než 7 jádry, tak by to bylo super.

V jedné z reakcí Arnd změnil svůj návrh, umožnil používání board files u podarchitektur, u kterých je nepravděpodobné, že budou v blízké budoucnosti podporovat stromy zařízení. V ten moment se diskuze uklidnila bez jakéhokoliv formálního zakončení. Toto téma bude pravděpodobně diskutováno na blížícím se Linaro Connect a dost možná i ještě potom. Je tu ještě řada dalších problémů, které se musí vyřešit, než se multiplatformní jádra pro ARM stanou realitou; to znamená, že je dostatek času na správné rozhodnutí, ke kterému se dospěje po zvážení všech relevantních potřeb.

Statistika vývojového cyklu verze 3.4

Při vydání předverze 3.4-rc6 dal Linus vědět, že konečné vydání 3.4 asi nebude daleko. To znamená jediné: je čas podívat se na statistiku tohoto vývojového ckylu. 3.4 byl dosti živý cyklus s překvapeními.

V době psaní tohoto textu Linus začlenil přes 10 700 změn do verze 3.4; tyto změny pocházejí od 1259 vývojářů. Celkový nárůst velikosti jádra je tentokrát kolem 215 000 řádek. Nejaktivnějšími vývojáři tohoto cyklu byli:

Nejaktivnější vývojáři cyklu 3.4

Podle počtu sad změn Mark Brown 284 2.7% Russell King 211 2.0% Johannes Berg 147 1.4% Al Viro 136 1.3% Axel Lin 133 1.2% Johan Hedberg 122 1.1% Guenter Roeck 121 1.1% Masanari Iida 109 1.0% Stanislav Kinsbursky 97 0.9% Trond Myklebust 85 0.8% Jiri Slaby 82 0.8% Ben Hutchings 82 0.8% Greg Kroah-Hartman 78 0.7% Takashi Iwai 78 0.7% Dan Carpenter 78 0.7% Stephen Warren 76 0.7% Stanislaw Gruszka 76 0.7% Alex Deucher 73 0.7%

Podle změněných řádek Joe Perches 56571 8.1% Dan Magenheimer 24077 3.4% Stephen Rothwell 17354 2.5% Greg Kroah-Hartman 15015 2.1% Mark Brown 12266 1.8% Jiri Olsa 11842 1.7% Mark A. Allyn 10976 1.6% Stephen Warren 10386 1.5% Arun Murthy 9347 1.3% Ingo Molnar 8779 1.3% Alex Deucher 8770 1.3% David Howells 8034 1.2% Guenter Roeck 7634 1.1% Chris Kelly 7023 1.0% Johannes Berg 6657 1.0% Ben Hutchings 6650 1.0% Al Viro 6628 0.9% Russell King 6610 0.9%

Mark Brown se nachází na vrcholu přispěvatelů už podruhé v řadě; jako obvykle odvedl spoustu práce kolem zvukových ovladačů a souvisejících subsystémů. Russell King je hlavním správcem ARM; aktivně se účastnil refaktorování a pročišťování kódu pro architekturu ARM. Johannes Berg nadále pracuje na vrstvě mac80211 a ovladači iwlwifi, Al Viro vylepšuje VFS API a opravuje chyby napříč jádrem a Axel Lin dělá spoustu pročišťování v ALSA a regulačních subsystémech.

Joe Perches vede v počtu změněných řádek díky opravám ve stylu kódu, změnám v pr_*() a souvisejícím věcem. Dan Magenheimer přidal mechanismus sdílení paměti "ramsterů do stromu staging. Údržbář Linux-next Stephen Rothwell se dostal do přehledu změněných řádek díky odstranění spousty starého kódu pro PowerPC. Greg Kroah-Hartman pracuje napříč stromem, ale většinu jeho práce najdeme ve stromu staging.

Do vývojového cyklu 3.4 přispělo nějakých 195 firem. Těmi nej tentokrát byly:

Nejaktivnější zaměstnavatelé v  3.4

Podle sad změn (žádný) 1156 10.8% Intel 1138 10.6% Red Hat 960 9.0% (Unknown) 688 6.4% Texas Instruments 428 4.0% IBM 381 3.6% Novell 372 3.5% (Consultant) 298 2.8% Wolfson Microelectronics 286 2.7% Samsung 234 2.2% Google 222 2.1% Oracle 188 1.8% Freescale 175 1.6% Qualcomm 161 1.5% Linaro 143 1.3% Broadcom 140 1.3% NetApp 133 1.2% MiTAC 133 1.2% AMD 132 1.2%

Podle změněných řádek (žádný) 108509 15.5% Intel 67464 9.7% Red Hat 65966 9.4% (Unknown) 50900 7.3% IBM 36800 5.3% Oracle 26617 3.8% Texas Instruments 25687 3.7% Samsung 24966 3.6% NVidia 20604 2.9% Linux Foundation 16917 2.4% ST Ericsson 15792 2.3% Novell 15185 2.2% Wolfson Microelectronics 14039 2.0% (Consultant) 13495 1.9% AMD 10151 1.5% Freescale 10102 1.4% Linaro 9360 1.3% Google 9070 1.3% Qualcomm 8972 1.3%

Stálicí v této tabulce je Red Hat jako nejlepší korporátní přispěvatel; ve verzi 3.4 byl ale Red Hat vytlačen Intelem. Příspěvky Red Hatu poklesly; ve verzi 3.4 jde jen o 960 sad změn v porovnání s 1290 ve verzi 3.3. Větší změnou je ale nárůst aktivity u Intelu. Jde hlavně o podporu pro hardware Intelu, ale jde i o věci, jako je podpora x32 ABI. Texas Instruments se nadále posouvají vzhůru stejně jako řada jiných společností kolem mobilních a embedded zařízení. Dříve se říkalo, že vývoji Linuxu vládnou velké korporace orientované na enterprise; tyto společnosti nikam nezmizely, ale už nejsou jediným tahounem. Příspěvků od dobrovolníků je podle trvajícího trendu opět méně než kdy předtím.

Rychlý pohled na ARM

V posledních vývojových cyklech bylo možné vidět spoustu práce na stromu ARM a verze 3.4 není výjimkou; tentokrát je to 1100 sad změn v arch/arm. Tyto změny pocházejí od 178 vývojářů, kteří zastupují 51 firem. Mezi těmito firmami byly nejaktivnější tyto:

Nejaktivnější zaměstnavatelé v 3.4 (strom ARM)
Podle počtu sad změn (konzultant) 149 13.5% Texas Instruments 121 11.0% (žádný) 103 9.4% Samsung 91 8.3% Linaro 80 7.3% NVidia 54 4.9% ARM 52 4.7% (Unknown) 48 4.4% Calxeda 46 4.2% Freescale 40 3.6% Atmel 37 3.4% Atomide 30 2.7% OpenSource AB 24 2.2% Google 23 2.1% ST Ericsson 23 2.1%	Podle změněných řádek Samsung 8162 16.8% (žádný) 5967 12.3% NVidia 4929 10.2% (konzultant) 4755 9.8% Linaro 3550 7.3% Texas Instruments 3118 6.4% ARM 2659 5.5% Calxeda 2408 5.0% Atmel 2080 4.3% (Unknown) 1862 3.8% Vista-Silicon S.L. 1121 2.3% Freescale 1117 2.3% Atomide 1005 2.1% Google 737 1.5% PHILOSYS Software 659 1.4%

ARM je jednoznačně místem, kde je spousta aktivních konzultantů; ti tentokrát přispěli více než 13 % změn. Jinak se v této oblasti nekonají žádná překvpení.

Na vývoj pro ARM se dá ale dívat i trochu jinak. Mnoho práce na ARM je děláno skrze konzorcium Linaro. Mnoho vývojářů, kteří přispívají z adresy linaro.com, jsou "najatí" z jiných firem; v této tabulce je co nejvíce práce přiřknuto skutečného zaměstnavateli, který za práci zaplatil. Kdyby ale všechno z adresy Linaro bylo na řádku Linaro, tak by právě Linaru patřilo 11,9 % všech změn v arch/arm, což by z něj dělalo hlavního zaměstnavatele, i když by počet změn byl stále měnší než od nezávislých konzultantů. Linaro se evidentně stalo důležitou součástí vývojářské komunity pro ARM.

Suma sumárum, šlo o další rušný a produktivní vývojový cyklus. Navzdory obvyklým zásekům se věci stabilizují a je tedy dost možné, že 3.4-rc7 bude poslední předverzí, takže tento cyklus by měl být celkem krátký. Jaderní vývojáři si ale moc neodpočinou; cyklus verze 3.5 se zběsilým začleňovacím oknem začne zanedlouho.

       

Komentáře

[pavlix]

Ale DNSSL nebude, že?

[Michal Kubeček]

Ne, bude v 3.5. Vzhledem k tomu, že v (druhé) odpovědi od Dana Williamse je i id commitu, není zase až tak těžké si to zjistit.

[pavlix]

Vzhledem k tomu, že v (druhé) odpovědi od Dana Williamse je i id commitu, není zase až tak těžké si to zjistit.

Rád se nechám poučit. S tím ID commitu jsem to právě chtěl najít a nepovedlo se mi to. Poradíš postup?

[Michal Kubeček]

Pokud je k dispozici naklonovaný Linusův git, tak např. pomocí

  git describe --contains e35f30c1

Momentálně to napíše "fatal: cannot describe ...", příští týden (?) už by to mělo ukázat něco, co bude začínat "v3.5-rc1-", kdyby byl commit ve 3.4, byl by na začátku odpovídající tag.

Přes webové rozhraní mne nic elegantního nenapadá, ale fungovalo by např. najít si ten commit, kliknout si na odkaz "commitdiff", pak si z hlavní stránky kliknout na tag v3.4, pak na "tree" a podívat se na některý ze souborů, které commit mění, jestli je tam patch aplikovaný nebo ne.

[pavlix]

Pokud je k dispozici naklonovaný Linusův git, tak např. pomocí

Tahle informace mi jaksi chyběla. Já jsem totiž vůbec netušil, jestli to v Linusově gitu bude (a v tu chvíli mi to nestálo za stahování), když to ještě vůbec není zařazeno.

Momentálně to napíše "fatal: cannot describe ...", příští týden (?) už by to mělo ukázat něco, co bude začínat "v3.5-rc1-", kdyby byl commit ve 3.4, byl by na začátku odpovídající tag.

Aha. Myslel jsem, že byl můj dotaz srozumitelný, ale jak vidím, tak jsem se měl napsat, že chci funkční postup a nepředpokládat, že je to zřejmé.

není zase až tak těžké si to zjistit.

Tedy ještě jednou. Rád bych k téhle velkohubé větě dostal i jeden funkční postup.

Přes webové rozhraní mne nic elegantního nenapadá, ale fungovalo by např. najít si ten commit

Mně je jedno jestli přes webové rozhraní nebo příkazovou řádku. Stačí mi jeden funkční obecný postup na nalezení commitu, o kterém se píše na mailing listu. Když sám píšeš, že to není až tak těžké.

Kdybych věděl, že budeš odpovídat totální nesmysly, budu se ptát jinde, že.

[Bubak]

Pokud mas strom stazeny, info o commitu ziskas pomoci "git log -1 id_commitu" (to -l je minus jedna). Mrkni na "git log --help", jak na to, pokud chces neco dalsiho.

[pavlix]

Já nepotřebuju návot na Git, ten používám denně a udělal jsem na něj už i pár školení. Používat manuál a google taky zvládnu. Michal ve svém předchozím komentáři psal, že mi to stejně vrátí chybu, protože tam ten commit prostě není.

[pavlix]

*návod

[Michal Kubeček]

Ale to je přece správně. V tuto chvíli je na otázku "který nejbližší tag je potomkem commitu e35f30c1" správná odpověď "žádný". Až vyjde 3.5 RC1, což by IIRC mělo být někdy v noci z neděle na pondělí, bude to "3.5-rc1". Tak jako tak je z kterékoli z těch dvou odpovědí (a toho, že ve stromu už je tag "v3.4") jasné, že ten commit ve verzi 3.4 není.

[pavlix]

Ale to je přece správně.

Správně ano, jen je to odpověď na jinou otázku :). Viz níže.

[Michal Kubeček]

Aha. Myslel jsem, že byl můj dotaz srozumitelný, ale jak vidím, tak jsem se měl napsat, že chci funkční postup a nepředpokládat, že je to zřejmé.

Co je na tom postupu konkrétně nefunkčního? Mně dává přesně takový výsledek, jaký dávat má.

Tedy ještě jednou. Rád bych k téhle velkohubé větě dostal i jeden funkční postup.

Uvedl jsem dva.

Mně je jedno jestli přes webové rozhraní nebo příkazovou řádku. Stačí mi jeden funkční obecný postup na nalezení commitu, o kterém se píše na mailing listu.

Ve webovém rozhraní je možné vyhledávat podle subjectu nebo autora. Podle hashe bohužel ne, ale to lze triviální obejít tak, že si zobrazím jakýkoli náhodně vybraný commit a přepíšu hash v URL.

Jako bonus ještě přidám zlepšovák pro Firefox:

1. otevřít stránku s jakýmkoli commitem
2. uložit kamkoli do bookmarků
3. najít, kliknout pravým, "vlastnosti"
4. hash v URL nahradit řetězcem "%s" (bez uvozovek)
5. do pole "klíčové slovo" napsat "kernel" a uložit
6. do adresního řádku napsat "kernel e35f30c1" a odeslat

Kdybych věděl, že budeš odpovídat totální nesmysly, budu se ptát jinde, že.

Kdybych měl šanci uhodnout, že chcete vědět něco jiného (jak najdu commit X), než na co se ptáte (jak zjistím, je-li commit X obsažen v release Y), tak bych odpovídal rovnou. Křišťálové koule nemaje, odpovíděl jsem na dotaz, který byl položen.

[pavlix]

Kdybych měl šanci uhodnout, že chcete vědět něco jiného (jak najdu commit X), než na co se ptáte (jak zjistím, je-li commit X obsažen v release Y)

Já se ptal pouze na replikaci tvého zjištění, že commit e35f30c1 bude v release 3.5.

Křišťálové koule nemaje, odpovíděl jsem na dotaz, který byl položen.

Byl bych potěšen, kdyby tomu tak bylo.

[Michal Kubeček]

Já se ptal pouze na replikaci tvého zjištění, že commit e35f30c1 bude v release 3.5.

Nelze samozřejmě zcela stoprocentně vyloučit, že Linus ten patch z nějakého důvodu revertne. Ale jelikož už v gitu je, tak pokud se tak nestane, tak prostě v 3.5 bude.

Byl bych potěšen, kdyby tomu tak bylo.

Ufff… Tak ještě jednou: zeptá-li se mne někdo, zda je něco v jádře 3.4, já mu odpovím že ne a on na to, jak to zjistit, pak prostě z kontextu předpokládám, že se ptá na to, jak zjistí, že v jádře 3.4 to není. To, že je-li patch v gitu a není v poslední dosud vydané verzi, pak bude v nejbližší vydané verzi (pokud ho někdo nerevertne, Linus se nerozhodne místo 3.5 vydat verzi 4, nenastane konec světa atd.), jsem prostě považoval za znalost, kterou lze v diskusi k Jaderným novinám předpokládat.

[pavlix]

Informace, že v Linusově gitovské větvi tento commit je, se ke mně dostala až tímto tvým komentářem. To ale znamená, že ten patch byl už Linusem přijat pro příští verzi, což je z mého pohledu nová informace.

Vše ostatní, o čem píšeš je jen balast, který předpokládá, že jsem tuto informaci měl k dispozici od začátku. Dan Williams uvedl pouze hash, který může mít commit v jakémkolik gitovském repozitáři v jakékoli větvi, což by měl vědět průměrný uživatel Gitu.

Ale každopádně díky, odpověď jsem tedy nakonec dostal.

Doufám, že smím i nadále číst jaderné novinky, i když nemám znalosti, kterými disponují vývojáři jádra a neznám přesný workflow jaderných gitovských repozitářů.

[Michal Kubeček]

Dan Williams uvedl pouze hash, který může mít commit v jakémkolik gitovském repozitáři v jakékoli větvi, což by měl vědět průměrný uživatel Gitu.

Pokud mne nějaká chyba nebo feature zajímá natolik, že se na ni zeptám v netdev listu, a dostanu odpověď "řeší to commit X" (bez určení repozitáře), tak se nejdřív podívám, jestli to není v tom hlavním Linusově, případně dalších, které by připadaly v úvahu (v tomto případě net a net-next Davea Millera). A když to nebude ani v jednom, tak se holt zeptám.

[pavlix]

To říká člověk neschopný přímo a na první pokus odpovědět na jednoduchou otázku, jak přišel na to, že DNSSL bude v release 3.5.

[Michal Kubeček]

Naposledy: odpověděl jsem na otázku, která byla položena. Hluboce a poníženě se tedy omlouvám vašemu blahorodí, že jsem si dovolil neuhodnout, co ráčilo vědět, a místo toho přízemně odpověděl na to, na co se ptalo. Slibuji, že už to víckrát neudělám a radši vám nebudu odpovídat vůbec, abych se podobného faux pas nedopustil znovu.

Howgh.

[Michal Kubeček]

Oprava: …co ráčilo chtít vědět…

[pavlix]

Howgh.

[petr sigut]

ja armu fandim, ale jako laikovi v tehle oblasti mi prijde ze je v nich trochu bordel - chybi neco jako bios ci nejaka minimalni kompatibilit. pak vyjde nejaky roztomily notebook s armem a je vubec problem tam linux dostat...

[j]

Ber to tak, ze ARM je prave proto tak oblibeny - ze to neni x86 moloch kde musis chte nechte implementovat hromady veci ktery na svym zarizeni vubec nepotrebujes.

[Petr Ježek]

Mít k dispozici společné detekční a init prostředky není znakem molochu, ale funkčním modulem na vyšší úrovni než jsou prvky. Takže znovu: Proč nejsou bezpochyby skvělé vlastnosti ARMu podepřeny univerzálním modulem umožňujícím nabootovat ARM všude tam, kde je nějaké uživatelské rozhraní podporované desktopovými a mobilními platformami?

[David Jaša]

K tomu jsou snad ty stromy zařízení v d fakin ártiklu, nebo tomu blbě rozumím?

[Filip Jirsák]

?board files? … Než se dopracujeme ke skutečné multiplatformní podpoře, tak se toho bude muset ještě hodně udělat ? například jde o práci na náležité abstrakci přerušení a hodin ? strom zařízení ale představuje důležitý krok.

Asi se někde poztrácely české uvozovky a pomlčky, jsou místo nich otazníky. Zkoušel jsem Chrome a Firefox, v obou je to stejné, takž eto nevypadá na problém v přijímači.

[Filip Jirsák]

A ještě na konci kromě uvozovek je také překlep direm -> firem.

jsou ?najatí? z jiných direm

[Petr Ježek]

Dobrovolníků je v příspěvcích vývoji méně, neb na rozdíl od výdajů na živobytí, které díky finančním trollům doléhají stále tíživěji a košile je blíže kabátu... To jen, kdyby se někdo naprázdno divil...