abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 21:44 | Nová verze

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 0
dnes 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
dnes 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 1
dnes 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 4
dnes 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 3
dnes 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 2
včera 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 10
včera 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
včera 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
16.10. 23:44 | Bezpečnostní upozornění

V Linuxu byla nalezena bezpečnostní chyba CVE-2017-15265 zneužitelná k lokální eskalaci práv. Jedná se o chybu v části ALSA (Advanced Linux Sound Architecture).

Ladislav Hagara | Komentářů: 1
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (13%)
 (2%)
 (0%)
 (2%)
 (73%)
 (10%)
Celkem 60 hlasů
 Komentářů: 4, poslední dnes 21:50
    Rozcestník

    Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM

    18. 4. 2011 | Jirka Bourek | Jaderné noviny | 4931×

    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ů.

    Obsah

    Aktuální verze jádra: 2.6.39-rc2

    link

    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.

    Citáty týdne: Ingo Molnár, Andrew Morton, Linus Torvalds, Mark Charlebois

    link

    A tento koncept lze dovést do logického závěru: myslím si, že je jenom otázkou času, než někdo vezme linuxové jádro, integruje do něj klibc a nějakou sadu nástrojů společně s dobrým počátečním uživatelským prostorem, s tím se odváže a vytvoří tak rozumný, 100% soběstačný OSS projekt, který bude sledovat vydávání jádra.

    -- Ingo Molnár

    Pro Orena je minimální sada patchů příliš minimální a maximální narazila na obecné nálady v jádře. Hádám, že budeš muset buď vzít minimální sadu a udělat z ní sadu o něco méně minimální, nebo vzít maximální sadu a udělat z ní méně maximální, čímž skončíš s jedním a tím samým. Co říkáš na tuhle zbytečnou zjevnost?

    -- Andrew Morton

    Už jsem to lidem říkal dřív a řeknu to znova: když nadávám podsprávcům, měli by se snažit předat to dál. Opravdu po nich nechci, aby čistili všechno, co dostávají: v podstatě je žádám o to, aby říkali „ne“ nebo aspoň hodně věcí tlačili zpátky a hádali se s lidmi, kteří zasílají kód. Řekněte jim, co se vám na kódu nelíbí, a že už to nemůžete snést.

    -- Linus Torvalds

    Mobilní prostor je o proprietárních ovladačích

    -- Mark Charlebois, Qualcomm Innovation Center (na přednášce na Linux Foundation Collaboration Summit)

    Citáty týdne II: in memoriam

    link

    Protože jsem to už viděl několikrát veřejně zmíněno, řekl bych, že si to zaslouží samostatné oznámení.

    Linux s nedávným skonem Davida Brownella ztratil skvělého vývojáře, kterého budeme velmi postrádat.

    -- Greg-Kroah Hartman

    David přispíval do mnoha oblastí, i rychlý pohled na MAINTAINERS ukáže, že pracoval na USB řadičích (OHCI, EHCI, OMAP a další), USB zařízeních, USB síťování a SPI. Měl vliv na základní návrh USB („lepící“ vrstva HCD a knihovna rozsyp-sesbírej) a na vývoj správy napájení (uspání systému a implementaci správy napájení v USB). Jeho návrhy byly elegantní a kód bylo vždy potěšením číst.

    Také hodně pomohl mně osobně, když mi pomohl vstoupit do vývoje základního kódu USB. A byl prvním člověkem, kterého jsem potkal na první konferenci o Linuxu, které jsem se účastnil. Také mi bude chybět.

    -- Alan Stern

    Myslím, že mnoho z nás má s Davem podobnou zkušenost. Mně také hodně pomohl, když jsem začal pracovat na vývoji Linuxu. Hodně jsem se naučil a budu ho postrádat. Jeho učení si sebou ponesu navždy.

    -- Felipe Balbi

    Bojiště jménem ARM

    link

    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:

    Proč? Vezměte si třeba svět Ubuntu. Pokud nemůžete vytvořit napůl obecné instalační obrazy, nemůžete mít rozumně obecnou distribuci. A když ji nemáte, jaká bude situace vašich vývojářů? Většina příčetných lidí se toho nedotkne třímetrovou tyčí, protože jim to prostě nebude stát za to.

    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:

    Na ARM nemáte žádná předinstalovaná „skutečná“ Windows. To vedlo lidi od hardwaru k tomu zkoušet různé věci. A proto hardware pořád mění, aby získali alespoň trochu navrch. A není to pro ně problém, protože po většinu času mají přístup ke zdrojovým kódům OS a sami si je přímo modifikují. Není divu, že je Linux na ARMu tak populární, jsem si jistý, že návrháři hardware si tuto svobodu opravdu užívají.

    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:

    Takže potřebujeme pomoc! Kdyby lidé od základního kódu jádra sestoupili ze svého stolce x86, snížili se do bláta ARM a pomohli ten bordel uklidit, bylo by to opravdu hezké (díky tglx.) Do té doby nás bude pár a všechno, co budeme moci dělat, je snažit se nějak zvládnout tu povodeň a doufat v nejlepší, přičemž doteď pro uživatele všechno v praxi fungovalo až překvapivě dobře....

    Nemůžeme počítat s tím, že by tuhle práci dělali lidé od výrobců. Ti mají spoustu práce s tím portovat jádro na novější verzi SOC, aby vyhráli cenu o nejlepší návrh hardware pro Android, a udělat to tak, aby dodrželi standardy pro kvalitu jádra je pro ně už teď docela problém.

    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:

    Jediný problém je najít osobu, která to bude ochotná dělat, bude mít dostatek zkušeností, široká ramena a silný akceptovaný hlas. A to nemluvím o někom, kdo bude ochoten platit dostatečně velkou kompenzaci za problémy a utrpení.

    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í.

    Linux Filesystem, Storage, and Memory Management Summit

    link

    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.

    Shrnutí o VFS

    link

    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.

    Přechodná paměť

    link

    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.

    Co bude následovat u řadiče paměti

    link

    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.

    Správa I/O zdrojů

    link

    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“.

    Odhad velikosti zpracovávaných dat

    link

    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.

    Nastavení velikosti virtuálních strojů

    link

    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.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    Petr Tomášek avatar 18.4.2011 06:44 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Typo
    18.4.2011 10:26 Patrik Uhrak | skóre: 31 | blog: pato
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    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:17 Sten
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    Ještě před pár lety mohl někdo jiný říct to samé o x86 nebo USB zařízeních. Situace se ale razantně změnila a dneska máme mnoho hardware používající obecné a tedy i otevřené ovladače (SATA řadiče, USB sítě, USB PTP, ty debilní „samoinstalační“ USB věci tvářící se před přepnutím jako flash disk, ...). A myslím, že v mobilní oblasti to bude ještě daleko rychlejší.
    Grunt avatar 18.4.2011 19:56 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    kde povolite urcite funkcie, lebo inak je to len nepouzitelny kus kremiku
    Tak 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.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    18.4.2011 20:41 Patrik Uhrak | skóre: 31 | blog: pato
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM

    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.

    19.4.2011 01:12 pc2005 | skóre: 34 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    No všechny tyhle věci jsou ale aspoň minimálně dokumentované. Do DSP si zkompilovat vlastní firmware, bytekódy asi budou taky. OpenGL nevím, neboť jsem nezkoumal. Tam by mohl být problém, protože grafiku má TI licencovanou odjinud.

    U mobilů bude hodně velký problém to, že dovolit otevřený ovladač pro vysílací část, si nikdo z výrobců netroufne :-(.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    Grunt avatar 20.4.2011 00:29 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    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í firmware
    To 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ů netroufne
    O 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.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    20.4.2011 04:15 pc2005 | skóre: 34 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    Do DSP si zkompilovat vlastní firmware
    To jo.
    Wow dokonce maj i jádro co na tom běží :-D. 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 :-D).
    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 :-D). 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 :-D.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    Grunt avatar 18.4.2011 17:14 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    Celý bordel v ARM architektuře nejlépe podtrhují Linusove komentáře #1 a #2. Kdyby člověk nevěděl o koho jde, tak by si normálně řekl, že má tu čest s nějakým dlaždičem.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    Grunt avatar 18.4.2011 17:16 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    Celý bordel v ARM architektuře
    Teda 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.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    18.4.2011 19:26 Sten
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    Ale on ten bordel je v samotné architektuře, přesněji samotná architektura způsobuje, že tam ten bordel vzniká. x86 má taky takový bordel v deskách, přesto se objevily standardy jako ACPI (na který tedy Linus tady nadává) a všechno to nějak rozumně nastaví BIOS (nebo UEFI). Na ARM nic takového není — všechno musí nastavovat jádro a proto je v jádře tak strašný bordel. Chybí tam prostě něco, co to nastaví (Linus tomu říká bootloader), aby se jádro nemuselo zabývat tím, jakou přesnou verzi desky tam zrovna výrobce dal a na jaké porty má poslat jaké příkazy, aby ji vyresetoval a spustil tak třeba řadiče úložiště.
    Grunt avatar 18.4.2011 20:01 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    Zas než BIOS nebo nějaký bootloader (u Broadcomackých boardů se to jmenuje CFE), tohle mi přijde trošku lepší. Jen by se ty boardfajly mohly vyházet do nějakého pre-initu (podobně jako třeba u x86 se zpracovávají pře hlavní smyčkou veškeré paramtery předané GRUBem, inicializace VGA, …), nějaké jedné tabulky a co by mohlo do ovaldačů, s tím do ovladačů. Takhle je to fakt hnus zelený (takový chudák Mrkva by mohl vyprávět).
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    skywaker avatar 18.4.2011 21:18 skywaker | skóre: 26 | blog: Lukove | Prešov
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM

    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

    Donate Bitcoins to Luko: 14mXEWw9tgTtRT35RSvLL27XSpyety8x3N
    Grunt avatar 18.4.2011 21:31 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    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.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    19.4.2011 01:18 pc2005 | skóre: 34 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    Velká spousta věcí s ARMem používá U-boot a ten podporuje devicetree, v něm můžou být tak lowlevel věci jako třeba MMIO adresy pro periferie čipu. To, že to tam nikdo nechce dát a že informace, na kterým pinu procesoru je jaký výstup, je v hlavičkovým souboru jádra je jiná věc :-D.

    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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    19.4.2011 08:38 R
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    Na beznej x86 zakladnej doske je vela veci, ktore musi BIOS nastavit (north bridge, south bridge, zvuk, siet, pridavne radice, super i/o, clock generator). Bootovat sa da napriklad aj zo siete. Alebo z radica vlozeneho v PCI slote. A vacsinou nova doska funguje bez toho, ze by sa museli zmenit vsetky OS, ktore tam chces prevadzkovat... Pokial ARM nebude mat toto vyriesene, tak z neho nikdy nebude konkurencia x86.
    19.4.2011 15:26 Jiří J. | skóre: 34 | blog: Poutník | Brno
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM

    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í.

    Víra je firma si myslela, že něco je pravdivé. LMAO -- “zlehčovat mého osla”
    19.4.2011 17:34 pc2005 | skóre: 34 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    x86 BIOS na zařízeních nastavuje jen základní věci, který si navíc stejně často OS nastaví sám znova. Na x86 je jednotnost tak velká, že výrobci BIOSů dodávaj jen šablony, možná ani to ne, aby si výrobci desek doslova naklikali kompatibilitu se svým čipsetem. K Awardu 4.5x tuším existoval dosovskej editor registrů chipsetu a jejich inicializačních hodnot.

    Tohle na ARMu není, resp. ARM je miniaturní část, jádro, které licencuje jedna firma. Už věci jako nastavení frekvence jsou řešený u každé firmy jinak.

    Bootování ze sítě je pořád málo. Teoreticky totiž jde bootovat z libovolného datového vstupu ;-). 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 :-D. 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 :-D.

    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č).
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    19.4.2011 18:47 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    a všechno to nějak rozumně nastaví BIOS
    ...na který Linus taky nadává ;-)
    Quando omni flunkus moritati
    stativ avatar 19.4.2011 20:15 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM
    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… :-D
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.