18.4.2011 06:44
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Rozbalit Rozbalit vše Typo
Portál AbcLinuxu, 10. května 2025 20:18
Aktuální verze jádra: 2.6.39-rc2. Citáty týdne: Ingo Molnár, Andrew Morton, Linus Torvalds, Mark Charlebois. Citáty týdne II: in memoriam. Bojiště jménem ARM. Linux Filesystem, Storage, and Memory Management Summit: Shrnutí o VFS, Přechodná paměť, Co bude následovat u řadiče paměti, Správa I/O zdrojů, Odhad velikosti zpracovávaných dat, Nastavení velikosti virtuálních strojů.
Současné vývojové jádro je 2.6.39-rc2, vydané 5. dubna. Bylo to až nezvykle klidné -rc2, za což bych měl být rád, ale upřímně jsem spíš podezřívavý. Chlapi, vy něco chystáte, že jo? Detaily vizte v kompletním changelogu.
Stabilní aktualizace: 31. března vyšlo jádro 2.6.35.12, opravuje dlouhý seznam chyb.
-- Ingo Molnár
-- Mark Charlebois, Qualcomm Innovation Center (na přednášce na Linux Foundation Collaboration Summit)
-- Alan Stern
-- Felipe Balbi
napsal Jonathan Corbet, 6. dubna 2011
Linuxové jádro podporuje širokou škálu architektur, některé z nich jsou výraznější než jiné. Architektura ARM obvykle nepřitahuje moc pozornosti, ale za poslední léta se stala jednou z nejvýznamnějších. V současnosti existuje obrovské množství embedded zařízení, na kterých běží Linux, protože jádro na ARM funguje dobře. Takže když se v konferenci objeví dlouhá a žhavá diskuze o kvalitě kódu architektury ARM, je dobré věnovat ji pozornost.
Začalo to počátkem začleňovacího okna 2.6.39, když Linus vznášel námitky k jednomu z mnoha požadavků na přetažení kódu pro subarchitekturu ARM. Stěžoval si na příliš velký ruch v architektuře, duplikace kódu, data specifická pro jednotlivé desky zabudovaná do souborů se zdrojovými kódy a na konflikty mezi jednotlivými požadavky na začlenění. Velká část dat specifických pro desku by podle něj měla z jádra zmizet do zavaděče; další navrhli, že velkou část problému by mohly vyřešit stromy zařízení [device tree]. V současnosti není možné přeložit jádro, které poběží na široké škále ARM systémů a to je podle Linuse problém pro celou platformu:
Ve skutečnosti se dokonce zdá, že existuje konsenzus o tom, v čem tkví zdroj problémů s architekturou ARM. Hardware jako takový se značně liší podle čipu, který se použije; nabídky systémů na čipu i od stejného výrobce nejsou vzájemně konzistentní a ještě horší je to, když dojde na produkty různých výrobců. Podle Nicolase Pitrea otevřenost Linuxu pomohla ARMu k úspěchu, ale je také součástí problému:
Architektura ARM je tedy masivní sbírkou „subplatforem“, každá z nich se spravuje nezávisle, často ji spravují jiní vývojáři a jenom málo z nich má čas a zájem pracovat na něčem, co bude společné pro více platforem. Výsledkem je nestálost kódu, mnoho duplicitních ovladačů a spousta hacků.
Situaci komplikuje fakt, že jádro je obětí vlastního úspěchu. Již několik let vývojáři hučí do průmyslu vyrábějícího embedded zařízení, aby pracovali s upstreamem a dostali svůj kód do jádra. Průmysl teď přesně tohle dělá; výsledkem je spousta kódu, přičemž ne všechen je tak hezký, jak bychom byli rádi. Fakt, že spousta výrobců embedded zařízení má jenom malý zájem či dlouhodobou vizi o tom, že by se řešilo něco jiného než okamžité problémy, věci zhoršuje. Výsledkem je kód, který „teď funguje“, ale který bude v dlouhodobém měřítku katastrofou, když dojde na údržbu.
Jak bude tento problém vyřešen? Zdá se, že architektura ARM potřebuje víc správců, kteří by se starali o záležitosti společné pro více platforem a kteří by zlepšovali stav podpory ARM jako celku. Lidé podle všeho souhlasí s tím, že správce ARM Russell King odvádí dobrou práci, co se základního kódu týče. Pak je zde pár lidí (Nicolas Pitre, Catalin Marinas, Tony Lindgren atd.), kteří se snaží vnést nějaký pořádek do bordelu subplatforem, ale zdá se, že se jim problém nedaří zvládnout. Jak řekl Nicolas:
Je pár vývojářů, kteří chtějí alespoň trochu pomoci. Projekt Linaro by zde mohl sehrát nějakou roli, ale stále zůstává nevyřešená otázka, jak má být kód pročištěn. Arnd Bergmann navrhl radikální krok vytvořit nový strom architektury ARM s novým čistým návrhem a podporu do něj přesunout. Starý kód by pak buď postupně zmizel, nebo by ho bylo možné použít k podpoře staršího hardware. Vytvořit novou architekturu se zdá být velkým krokem, ale došlo k tomu již dříve a ne jednou. Architektura x86-64 byla v podstatě čistým startem z x86; obě platformy pak nakonec byly spojeny zpátky do mnohem čistšího stromu. Podpora pro PowerPC prošla podobným procesem.
Jestli na to dojde i u ARM, se uvidí; jsou zde jiní vývojáři, kteří by raději pročištění provedli postupně u existujícího stromu ARM. Tak jako tak bude prvním krokem najít vývojáře, kteří na tom budou ochotni pracovat. Není nedostatek vývojářů, kteří by měli zájem o ARM, ale jenom málo z nich je ochotno a schopno věnovat se vysokoúrovňové práci na architektuře – a vypořádat se s nevyhnutelným odporem k tomu něco měnit. Jak řekl Thomas Gleixner:
Je zde tedy výzva, se kterou se musíme vypořádat. Platforma ARM má ale velkou ekonomickou hodnotu a mnoho lidí v dané oblasti pracuje a chápe, kde jsou problémy. Je tedy slušná šance, že se najde nějaké řešení.
napsal Jonathan Corbet, 5. dubna 2011
Od Linux Filesystem, Storage, and Memory Management Summit 2010 v Bostonu uplynulo pouhých 8 měsíců, ale to neznamená, že nebylo o čem mluvit – nebo že by nebyl čas hodně udělat. Za těch osm měsíců došlo k velkým nebo dokonce zásadním pokrokům v mnoha oblastech, které byly diskutovány loni: zlepšení zpětného zápisu [writeback], lepší ošetření chyb, transparentní velké stránky, řadič I/O propustnosti a přepracování blokové vrstvy. Některé úkoly naopak zůstávají nesplněné, ale i zde je naděje: Trond Myklebust na úvodní přednášce summitu 2011 řekl, že to je možná naposledy, kdy bude nutné diskutovat pNFS – což je vyhlídka, se kterou nikdo neměl problém.
Následující články jsou zprávou z prvního dne setkání, které se konalo 4. dubna. Jejich záběr je samozřejmě nekompletní; když se skupina dělila na více diskuzí, autor článku sledoval ty o správě paměti.
James Bottomley začal diskuzi o vrstvě virtuálního souborového systému poznámkou, že přes fakt, že začlenění patchů škálovatelnosti VFS od Nicka Piggina obklopovalo mnoho „procesních záležitostí“, má se daná diskuze týkat pouze záležitostí technických. Diskuzi vedl Nick Piggin, původně se toho měl ujmout Al Viro, ale ten se nemohl zúčastnit kvůli zdravotním problémům. Jak se ukázalo, Nick chtěl mluvit o procesních záležitostech, takže mnoho času bylo stráveno jimi.
Začlenění práce na škálovatelnosti podle něj nebylo ideální. Patche byly k dispozici přibližně rok, ale podle Nickových informací nebyly v době začlenění dostatečně revidovány. To Linus věděl také, ale rozhodl se je začlenit i tak, aby ostatní donutil se na ně podívat. To se vydařilo, ale cenou za to byly potíže pro vývojáře VFS.
Andrew Morton komentoval, že začlenění patchů nebyl velký problém; někdy je jedinou možností, jak se pohnout kupředu, prostě do jádra „něco narvat a pak to opravit.“ Podle něj bylo skutečným problémem to, že po začlenění patchů Nick zmizel; nebyl k dispozici, aby mohl další práce podpořit. Vývojáři by rozhodně měli být k dispozici, když se takováto změna začleňuje. Andrew řekl, že pokud to bude nutné, je ochoten opřít se do nadřízeného daného vývojáře, pokud to bude potřeba.
V každém případě je kód v jádře a z větší části funguje. Automounter autofs4 je podle všeho „stále nemocný“, ale to nemusí být nutně důsledkem práce na VFS – ve stejnou dobu bylo začleněno mnoho změn přímo v automounteru.
Otevřenou záležitostí zůstává to, že bezzámkové vyhledávání dentry nelze použít pro adresář, který má rozšířené atributy nebo když je aktivní nějaký bezpečnostní modul. Nick tento problém potvrdil, ale v současnosti nemá žádné okamžité řešení; na tom se bude pracovat v budoucnu. Podpora bezzámkového vyhledávání v takových situacích zjevně bude vyžadovat změny ve vrstvě VFS i v souborových systémech.
V projektu, na kterém chce Nick pracovat, je cílem vytvořit seznamy datových struktur, jako jsou dentry a inode specifické pro jednotlivé NUMA uzly, což by je umožnilo rušit podle zadaného uzlu. V současnosti může nedostatek paměti na NUMA uzlu způsobit zahození dentry a inodů na všech uzlech, i když jinde v systému nemusí být s pamětí problém. Christophu Hellwigovi se tento nápad moc nelíbil a navrhl Nickovi, ať si to zkusí a uvidí, jak špatně to bude fungovat. Podle všeho je problémem mimo jiné to, že u mnoha souborových systémů nelze inode odstranit z paměti, dokud všechny s ním spojené stránky nejsou uloženy na disku. Nick řekl, že to je problém, který je potřeba opravit, protože to ztěžuje správu paměti.
Dan Magenheimer vedl diskuzi o své práci na přechodné paměti. Základní myšlenka přechodné paměti [transcendent memory] – paměť, kterou lze adresovat pouze na základě stránek, ale která není přímo viditelná pro jádro – je stále stejná, ale použití je víc. Doteď byla spojena s virtualizací (konkrétně s Xenem), ale Dan říká, že se ji snaží natlačit k obecnějšímu používání a za posledních šest měsíců nenapsal jedinou řádku kódu pro Xen.
Na čem tedy pracoval? Výsledkem je „zcache“, mechanismus pro kompresi obsahu paměti do paměti, který byl v 2.6.39 začleněn do stromu staging. Objevuje se čím dál větší podpora pro zařízení, která mají rozšířit objem dostupné RAM – například v podobě úložišť bez rotujících částí a paměťových zařízení se změnou fáze. Modul „ramster“ je určitým druhem mechanismu pro peer-to-peer paměť, umožňuje přesouvat stránky v rámci clusteru; systémy, které mají volnou paměť, mohou hostovat stránky pro systémy, které jí mají málo. A ano, přechodnou paměť lze stále využívat k přesouvání RAM do a z virtuálních strojů.
To vše lze podporovat za patchi cleancache a frontswap, které Linus nezačlenil do 2.6.39-rc1. Ještě neřekl „ne“, ale šance na začlenění do 2.6.39 podle všeho rapidně klesají.
Hugh Dickins vystoupil s obavou, že frontswap bude pravděpodobně poměrně brzy po startu zaplněn a skončí tam kód pro inicializaci aplikací, který pravděpodobně už nikdy nebude zapotřebí. Jak se zajistí, aby oblast frontswap nebyla zaplněna zbytečnostmi? Dan potvrdil, že to by mohl být problém; jedním řešením je mít démona, který by tyto stránky z frontswapu opět načetl do paměti, když jí bude dost. Hugh měl obavu, že v dlouhodobém měřítku bude jádro potřebovat nové datové struktury, které budou sledovat stránky vkládané do hierarchického systému swapování a že frontswap, který takové sledování postrádá, by mohl být krok špatným směrem.
Andrea Arcangeli řekl, že vlastnost jako zcache by mohla být užitečná i pro hosty běžící pod KVM. Dan souhlasí, že by to bylo hezké, ale on (jako zaměstnanec Oracle) to nemůže implementovat.
V diskuzi o budoucím směřování tohoto řadiče vystupovali lidé, jejichž mateřským jazykem nebyla angličtina a kteří mluvili poměrně potichu, takže poznámky autora článku zde bohužel nejsou kompletní.
Jedním z témat, které se objevovalo opakovaně, byla duplikace seznamu nejdéle nepoužívaných stránek [least-recently used, LRU]. Základní kód virtuální paměti udržuje LRU seznamy a snaží se pomocí nich zjistit, které stránky se nejdéle nepoužívaly a které tedy pravděpodobně nebudou v nejbližší budoucnosti zapotřebí. Řadič paměti pro každou řídící skupinu [control group] udržuje vlastní LRU seznam, což vede k plýtvání, protože se stejná práce dělá dvakrát. Je velká snaha tento problém vyřešit tak, že se globální LRU seznam odstraní a veškerá správa paměti bude probíhat na základě seznamů specifických pro řídící skupinu. Toto téma se později ještě objevilo.
Hiroyuki Kamezawa si stěžoval, že řadič paměti v současnosti sleduje součet využívání RAM a swapu. Podle něj by bylo dobré oddělit využívání swapu z řadiče paměti a zabývat se jím samostatně.
Opět se objevila správa paměti jádra. Konsenzus je, že to je složitý problém, ale je mnoho důvodů se jím zabývat. Prvním krokem by nicméně mělo být jednoduché sledování využívání paměti jádrem; aplikace limitů může přijít později. Pavel nicméně poznamenal, že nikdy nebude možné sledovat využívání veškeré paměti; některé alokace nikdy nebude snadno možné spojit se specifickou řídící skupinou. Příkladem jsou alokace v obsluhách přerušení. Také není žádoucí, aby alokace v jádře selhala, i když je řídící skupina nad svým limitem; cena za to by prostě byla příliš velká. Možná by bylo lepší zaměřit se na specifické zdroje problémů. Tabulky stránek jsou podle všeho datovou strukturou, která dokáže zabrat hodně paměti a kde by dávalo smysl vytvořit limity.
Trochu se diskutovalo o způsobu, jak se účtují sdílené stránky. V současnosti je stránka naúčtována té skupině, která se jí dotkne první; všichni další uživatelé ji mají zadarmo. Pokud tedy jedna řídící skupina načte celou C knihovnu, omezí si tím další využívání paměti, zatímco všichni ostatní jedou zadarmo. V praxi nicméně toto chování nebude velkým problémem; řídící skupině, která má moc sdílených dat, se nějaká odeberou, čímž náklady přeberou ostatní. Postupem času bude účtování sdílených stránek v systému rozděleno rovnoměrně, takže se nezdá, že by byl potřeba nějaký složitější mechanismus, který by je sledoval.
Hlavním tématem, které se často objevovalo v diskuzní větvi zabývající se správou paměti, často byly „řídící skupiny“; v jednom případě nicméně tuto zábavu sdíleli všichni, protože Vivek Goyal, Fernando Cao a Chad Talbott vedli diskuzi o řízení I/O propustnosti. V jádře jsou aktuálně dva řadiče: omezující (který může řídící skupině omezit absolutní hodnotu propustnosti) a proporcionální (který dělí dostupnou propustnost mezi skupiny podle politiky nastavené správcem.) Vivek mluvil o omezujícím řadiči, který je v jádře: ten funguje, ale stále má pár nedořešených záležitostí.
Jednou z nich je, že moc dobře nefunguje u žurnálovacích souborových systémů. Požadavky těchto souborových systémů na pořadí I/O operací nedovolí zapsat žurnál na disk, dokud nebyly zapsány jiné operace; pokud byla některá z nich omezena řadičem, zápisy žurnálu se zabrzdí a celý souborový systém zpomalí. Dalším problémem je, že řadič může pracovat pouze se synchronním zápisem; zápisy, které prošly bufferem v cache stránek, ztratily informaci o původní řídící skupině a nelze je účtovat do její kvóty. Pro omezování bufferovaných zápisů existují patche, ale jsou komplikované a rušivé.
Na další problém upozornil Ted Ts'o: omezující řadič aplikuje limity propustnosti podle zařízení. Když se používá souborový systém btrfs, může ho tvořit více zařízení. Správce téměř určitě bude chtít aplikovat limity na celou skupinu [volume group], ale to teď řadič neumí. S tím souvisí problém, že někteří uživatelé chtějí možnost aplikovat globální limity – limity na součet propustnosti pro všechna zařízení dohromady. Omezující řadič také nefunguje se souborovými systémy NFS; pod nimi není žádné zařízení, takže není kam umístit limit.
Chad Talbott mluvil o proporcionálním řadiči propustnosti; ten funguje dobře, co se čtení a synchronních zápisů týče, ale stejně jako omezující řadič není schopen pracovat s asynchronními zápisy. Oprava tohoto problému bude vyžadovat vložit do zapisovacích vláken pro jednotlivá zařízení nějaké informace o řídících skupinách. Systém v současnosti udržuje pro každé zařízení seznam obsahující inody se špinavými stránkami; tyto seznamy bude nutné ještě rozdělit na seznamy specifické pro řídící skupinu, aby zapisovací vlákno mohlo data zapsat podle nastavené politiky. Řadič také ještě správně neimplementuje hierarchické skupinové plánování, ale pro přidání této funkcionality existují patche.
Následující diskuze se zaměřila na to, jestli se v systému nehromadí příliš mnoho řídících skupin. Místo spousty řadičů pro jednotlivé subsystémy bychom ve skutečnosti měli mít nějaký mezisubsystémový řídící mechanismus. V tuto chvíli máme v jádře nicméně řídící skupiny (a s nimi spojené API pro uživatelský prostor, které nelze porušit.) Takže i když někteří (jako James Bottomley) navrhovali, že bychom existující řídící skupiny měli zahodit a udělat místo nich něco, co bude správně, bude to asi příliš velký požadavek. Krom toho, jak řekl Mike Rubin, ani teď vlastně nevíme, jak by řídící skupiny měly vypadat. U návrhu rozhraní chyběli lidé se „vkusem a stylem“.
V diskuzní větvi o správě paměti se Michel Lespinasse věnoval kódu pro odhad velikosti zpracovávaných dat [working set estimation] od Googlu. Google tento mechanismus již nějaký čas používá jako způsob, jakým optimálně umístit nové úlohy na svůj masivní cluster. Když zjistí, kolik paměti každá úloha skutečně používá, mohou najít stroje s největším počtem nečinných stránek a práci poslat na ně. Kód tedy jinými slovy Googlu umožňuje lépe rozhodovat o tom, jak vytížit své systémy.
Implementace je jednoduché jaderné vlákno, které ve výchozím nastavení jednou za dvě minuty prohledá fyzické stránky v systému. Na každou se podívá a zjistí, jestli se jí uživatelský prostor dotkl a tento stav si zapamatuje. Základní myšlenkou je zjistit, kolik stránek lze systému sebrat, aniž by se tím způsobil nevhodný tlak na paměť.
Jaderné vlákno funguje tak, že pro každou stránku, na kterou se podívá a která nebyla použita, nastaví příznak „nečinná“ [idle]. Tento bit je vynulován, pokud se ke stránce přistoupí (což se zjistí tím, že subsystém VM vynuluje bit „mladá“ [young].) Stránky, které jsou při po sobě jdoucích prohlídkách stále označené jako nečinné, se považují za nevyužívané. Kód pro odhadování nedělá nic, aby tyto stránky odebral; pouze v souboru specifickém pro řídící skupinu tyto informace exportuje. Číslo se dělí na čisté, špinavé – zálohované swapem a špinavé – patřící souboru. Co s touto informací udělá, to už je na kódu v uživatelském prostoru.
Padly otázky ohledně režie prohledávání stránek; Michel řekl, že prohledávání každé dvě minuty vyžaduje cca 1% dostupného času CPU. Také se objevily dotazy na využívání dalších dvou příznaků stránek; tyto příznaky jsou na 32bitových systémech omezenou komoditou. Padl návrh použít oddělenou bitovou mapu mimo strukturu page. U Google nicméně všechno běží v 64 bitovém režimu, takže o vyčerpání příznaků stránek se tam moc nestarají. Rik Van Riel navrhl, že by tuto vlastnost možná šlo jednoduše na 32 bitových systémech nepodporovat. Také dodal, že by mohla být užitečná i v jiných kontextech; systémy, na kterých běží KVM hosté, by ji například mohly používat k řízení alokace paměti pomocí balónového ovladače.
Rik vedl diskuzi na téma jak alokovat správný objem paměti virtuálním strojům. Stejně jako u mnoha problémů i zde jsou dva samostatné aspekty: politika (zjistit, jaká je pro daný virtuální stroj správná velikost) a mechanismus (skutečná implementace rozhodnutí). Problémy jsou na obou stranách.
Pro řízení toho, kolik paměti bude mít virtuální stroj k dispozici, existuje mnoho mechanismů. K alokaci paměti v hostech, aby ji bylo možné dát k dispozici hostiteli, existují „balónové ovladače“; když je potřeba hosta zmenšit, balón se „nafoukne“, takže donutí hosta některé stránky uvolnit. Informování o stránkách [page hinting] je mechanismus, pomocí kterého může host informovat hostitele, že některé stránky neobsahují užitečná data (například jsou na seznamu volných stránek hosta). Hostitel poté může získat paměť tak, že tyto stránky přebere, aniž by je zapisoval na trvalé úložiště. Hostitel také může jednoduše odswapovat stránky hosta, aniž by přitom nějak zapojil jeho operační systém. Mechanismus KSM umožňuje jádru získat stránky, které obsahují duplicitní data. Data lze pomocí komprese namačkat do menšího množství stránek. Obsah stránek lze jednoduše přesouvat mezi systémy nebo naskládat do nějakého schématu, které využívá přechodnou paměť.
Na straně politiky je možností méně. Patche pro odhad velikosti zpracovávaných dat [working set estimation] jsou rozhodně jednou možností. Využití paměti lze řídit jednoduše tím, kam je virtuální stroj umístěn. Mechanismus přechodné paměti také hostiteli umožňuje rozhodovat o tom, jak rozdělit paměť mezi hosty.
Jednou zajímavou možností, kterou navrhl Rik, je vylepšit mechanismus balónu. Současné balónové ovladače většinou nutí uvolnění náhodných stránek; to u hostitele vede k fragmentaci a omezuje pokusy používat velké stránky. Lepším přístupem by mohlo být použít informování o stránkách, což by hostu umožnilo sdělit hostiteli, které stránky jsou volné. Balónový ovladač by potom mohl fungovat tak, že by se zvýšily hranice pro volnou paměť místo toho, aby se zabraly stránky samotné; to by hosta nutilo udržovat více volných stránek. A co je ještě lepší, do hry by přišlo i shlukování paměti, takže by host byl nucen uvolňovat spojité rozsahy stránek. Vzhledem k tomu, že takové stránky jsou označené jako volné, hostitel je může sebrat (při troše štěstí jako velké stránky) a použít jinde. S tímto přístupem není nutné předávat stránky přímo hostiteli; předání informací je dostatečné.
Jsou i další důvody, proč se vyhnout přímému alokování stránek v balónových ovladačích; jak upozornil Pavel Emelyanov, tato situace může vést v hostovi k situacím, kdy dojde paměť. Andrea Arcangeli prohlásil, že když se používají balónové ovladače, host musí být nakonfigurován tak, aby měl dostatek swapu a tomuto problému se vyhnul; věci jinak nebudou stabilní. Politika implementovaná současnými balónovými ovladači je zcela určena hostitelským systémem; v současnosti není možné nechat hosta rozhodnout o tom, kdy se potřebuje rozrůst.
Také je tu jednoduchý problém komunikace; hostitel nemá žádný podrobný přehled o potřebách hosta, co se paměti týče. Opravit tento problém nebude jednoduché; jakékoliv rušivé monitorování hosta a jeho využívání paměti nebude dobře škálovat. A monitorování většinou funguje špatně, když se v hostovi změní vzor využívání paměti – což se děje často.
Z této diskuze vzešlo jenom málo závěrů. Během několika týdnů Rik bude mít novou sadu patchů pro informování o stránkách; poté lze přemýšlet nad tím provádět balónování zcela pomocí předávání informací, aniž by bylo nutné volat hostitele.
Mobilní prostor je o proprietárních ovladačích
-- Mark Charlebois, Qualcomm Innovation Center (na přednášce na Linux Foundation Collaboration Summit)
Myslim, ze zozal nesmierny uspech. Kazdopadne, ak tym mysli, ze je nutne si nainstalovat windows (odsuhlasenie licencie == zaplatenie v idealnom svete), kde povolite urcite funkcie, lebo inak je to len nepouzitelny kus kremiku. Plus to, ze firmware sa distribuuje len pre windows a nie je ho mozne distribuovat dalej podla ich licencie. Mam tedka na mysli Gobi 2000 od Qualcomm a nerobim si iluzie, ze cokolvek z ich ruk bude o moc privetivejsie po takychto vyhlaseniach. Cokolvek skonzumol, uskodilo to.
Ale aby som nebol nespravodlivy, tak nie su jediny (intel 3945 na dell xps ma rovnaku featuru ohladne nutnosti pouzitia windows jednorazovo pre jeho zapnutie a dalsi urcite pribudnu), ale nech aspon neprovokuje.
18.4.2011 19:56
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
kde povolite urcite funkcie, lebo inak je to len nepouzitelny kus kremikuTak až zas tak razantní to není. Ale třeba Cortexy-?{0-9} poskytují nativní vykonávání Java bytekódu přímo na procesoru (Dřív Jazelle, teď už ví čert jak se to jmenuje; jinak je to logické – OMAP je mobilní platforma a nějaká ta mobilní Java tam stále frčí) a bez nějakého toho propritárního ovladače poskytovaného jen velkým výrobcům mobilních zařízení je to nefunkční. No furt je možné SW emulovat pomocí OpenJDK (zas kdo ví co to je OpenJDK na nějakém 500-800Mhz Cortexu ví do jaké míry je to funkční). Stejně jako když někdo nechce používat uzavřené OpenGLES knihovny, může emulovat SW pomocí Mesy (znova, kdo ví co je to SW render MESy na 3Ghz x86 asi má představu jak to musí fungovat na tom Cortexu). Nebo třeba když někdo nechce binární BIOS a moduly do DSP, může dekódovat pomocí mplayeru nebo gstreameru.
Ja sa tu nesnazim o nejaku revoluciu, ale tak wifi karta intel 3945 v dell xps sa nedala nijako inak zapnut, len ze sa spustili windows a tam sa zapla. Stacilo tak spravit len raz v zivote tej karty. Terajsia Gobi 2000 je na tom o trosku lepsie, lebo bez windows by mi nefungovalo "iba" GPS. Lebo tu mame wine, kde je nastastie mozne ziskat firmware z ovladacu pre tu kartu. Ale naco si kupovat nieco s GPS, ked to nie je mozne spustit. A keby som chcel byt velice poctivy, tak by som si musel dokupit windows alebo odsuhlasit aspon licenciu.
Skutocne, pri oboch tychto zariadeniach som stravil nejaky nemaly cas hladanim riesenia a vzdy bolo iba jedno a to viedlo cez windows. Pozri na thinkwiki alebo na inych weboch o Gobi 2000 a urcite najdes aj o dell xps 1530 ci tej karte samotnej.
.
20.4.2011 00:29
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
No všechny tyhle věci jsou ale aspoň minimálně dokumentované.Jasně. Tohle je proti x86 docela rozdíl.
Do DSP si zkompilovat vlastní firmwareTo jo.
bytekódy asi budou taky.Jak pro co? Pro Jazzele? Tak to právě nevím a aspoň já o ničem nevím. Link by byl náležitě oceněn.
OpenGL nevím, neboť jsem nezkoumal.Na tom není co zkoumat. SDK (tedy nějaké halavičkové soubory) pro GLES jsou otevřené k vývoji, ale samotné jádro je uzavřené (jaderná část zobrazovadla je zas otevřená).
U mobilů bude hodně velký problém to, že dovolit otevřený ovladač pro vysílací část, si nikdo z výrobců netroufneO tom se nebavím vůbec. Že pro OMAPy a jiné ARM platformy existuje i nějaký GSM modul ignoruju úplně, protože to je dílo čertovo.
Wow dokonce maj i jádro co na tom běžíDo DSP si zkompilovat vlastní firmwareTo jo.
. Myslím, že původně bylo c64x proprietární, ale teďka si to nemůžou dovolit imho, jednak dělaj SoC jen s c64x jádrem, jednak jich dělaj hodně a jednak pro věci, kde na minimálních chybách hodně záleží. Osobně bych řekl, že trh je donutil. Jakmile na c64x (vlastně c6x jenom) poběží linux, tak ta platforma prostě nemůže být zavřená (a že by jejich BIOS tomu linuxu emuloval prostředí o tom pochybuju ).
Jak pro co? Pro Jazzele? Tak to právě nevím a aspoň já o ničem nevím. Link by byl náležitě oceněn.Nový cortexy maj tu Jazelle jen softwarově emulovanou. Thumb2 je podporován GCC. ThumbEE (Jazelle RCT = Thumb2 + vylepšení v JIT nasazení) je podporován v jádru.
Na tom není co zkoumat. SDK (tedy nějaké halavičkové soubory) pro GLES jsou otevřené k vývoji, ale samotné jádro je uzavřené (jaderná část zobrazovadla je zas otevřená).Aha takže v případě Imagination SGX5, který je hardwarový je i to API proprietární? Hmm tak to by byla škoda. Jinak by šlo vykašlat se na proprietární nebo softwarový kernel a udělat si wrapper mezi hardwarem a GLES hlavičkama - imho minimální. Osobně jsem čekal, že c64x nebude otevřený natolik aby na něm běželo jádro a u 3D akcelerátoru jsem určitou proprieraritu čekal (je to jen licencovaný IP core
- od nějaké "neznámé" firmičky ). Jazelle je problém, ale jestli je něco lepšího, tak OK. Teď otázka jak otevřenost zvýšit. Maximálně mě napadá buď prudit vlastníky práv nebo TI (a spol) navrhnout openHW core .
18.4.2011 17:14
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
18.4.2011 17:16
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Celý bordel v ARM architektuřeTeda ať se opravím – Ne v architektuře jako takové (ale i tam je docela slušný bordílek), ale právě v arch stromu v Linuxu a různých subarchitekturách.
18.4.2011 20:01
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
18.4.2011 21:18
lukve | skóre: 29
| blog: Lukove
| Prešov
takze nakoniec dospejeme k tomu ze to ze maju x86 jednotny BIOS a ze niekedy existoval DOS od jednej zaujimavej :) firmy ktora bios velmy vyuzivala viedlo v historii k tomu ze x86 su jednotnejsie co do platformy?
inac dragonflybsd ma rozdelene /cpu a /platform narozdiel od inych BSD ktore to maju vsetko v jednom /arch ako to ma linux pokope
18.4.2011 21:31
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
takze nakoniec dospejeme k tomu ze to ze maju x86 jednotny BIOS a ze niekedy existoval DOS od jednej zaujimavej :) firmy ktora bios velmy vyuzivala viedlo v historii k tomu ze x86 su jednotnejsie co do platformy?To jsem řekl? Ale i kdyby, furt to není plus.
.
Imho kdyby na x86 bylo tolik věcí co se dá konfigurovat, tak by to žádný BIOS taky neutáhl. Už třeba jen fakt, že bootovat se dá i odjinud než jen z USB/HDD/FDD/DVD.
To by se výrobci museli přestat předhánět v soutěži "kdo vymyslí víc nových rozhraní", což asi jen tak nenastane. To by se Linus musel hecnout a nepullovat celý strom, dokud někdo nevymyslí něco unifikovaného, co by respektovaly všechny společnosti. Což nehrozí.
. Osobně já bootoval například přes sériový port a kdybych si neodpálil parport, tak i z něj. Ale obecně by mělo jít třeba i přes zvukovku . Na ARMu pak jsou věci jako 2-3 různý sériový synchronní protokoly, asynchronní protokol, USB, volné adresovací piny a další sběrnice, o kterých jsem ani nikdy neslyšel. Tam pak jsou periferie různý (pokud existujou) nejen mezi výrobci (hardwarově), ale i mezi jednotlivými řadami a dokonce mezi jednotlivými deskami a to možná i mezi jedním modelem. Na rozdíl od x86 lze totiž často u embedded procesorů konfigurovat na jaký pin bude vyvedeno jaké zařízení. Takže aby to mohl nějaký univerzální BIOS obsáhnout, tak by musel mít brutální databázi všech kombinací - stejně jako to teďka má jádro. Imho by to šlo právě pomocí devicetree, což by si pak jádro naparsovalo a podle toho zavedlo případně ovladače. Proč se to globálně nepoužívá nevím, ale onen U-Boot to 100% podporuje.
BTW Z ARMu nikdy nebude konkurence x86, protože proč by snižoval svoje portfolio .
Jinak on by strom arch/arm/ nebyl tak velkej, kdyby nebyly ovladače zařízení (časovač, sériák (!) a další) právě v něm (taky nechápu proč).
a všechno to nějak rozumně nastaví BIOS...na který Linus taky nadává
19.4.2011 20:15
stativ | skóre: 54
| blog: SlaNé roury
Ale on ten bordel je v samotné architektuře, přesněji samotná architektura způsobuje, že tam ten bordel vzniká.Kde jsem to jen viděl… Jo aha, u distribucí GNU/Linuxu…
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.