Jaderné noviny – 27. 11. 2013: ACPI na ARM?

17. 12. 2013 | Luboš Doležel

Články - Jaderné noviny – 27. 11. 2013: ACPI na ARM?  

Aktuální verze jádra: 3.13-rc1. Citáty týdne: Thomas Gleixner, Arnd Bergmann. Nástroj pro checkpoint/restore v1.0. Facebook má rád Btrfs. Závěr začleňovacího okna 3.13. ACPI pro ARM: Argumenty pro a proti; Co s tím.

Obsah

• Aktuální verze jádra: 3.13-rc1
• Citáty týdne: Thomas Gleixner, Arnd Bergmann
• Nástroj pro checkpoint/restore v1.0
• Facebook má rád Btrfs
• Závěr začleňovacího okna 3.13
• ACPI pro ARM?
  • Argumenty pro a proti
  • Co s tím

Aktuální verze jádra: 3.13-rc1

Aktuální vývojová verze jádra je 3.13-rc1 vydaná 22. listopadu. Nakonec bylo během tohoto začleňovacího okna přetaženo 10 518 neslučovacích změn. Nyní začíná fáze stabilizace, přičemž konečná verze 3.13 by měla vyjít ke konci roku.

Stabilní aktualizace: za poslední týden žádné nevyšly. Verze 3.12.2, 3.11.10, 3.10.21 a 3.4.71 se aktuálně revidují; jejich vydání můžeme očekávat 28. listopadu nebo později. Pozor na to, že 3.11.10 bude poslední aktualizací v řadě 3.11.

Citáty týdne: Thomas Gleixner, Arnd Bergmann

U futexů víra nestačí. Buď jim zcela rozumíte, nebo je zkrátka necháte na pokoji.

-- Thomas Gleixner

Z vašeho popisu to vypadá, že se SPECTRE vlastně snaží operačním systémům práci trochu ušetřit, a to definicí standardní hardwarové platformy. Pokud toto opravdu vyjde a lidé od hardwaru to moc nezkazí, pak se nemusí nad podporou tohoto hardwaru váhat a nevidím zásadní problém s přidáváním podpory ACPI pro něj. [...]

Bohužel není v této fázi možné vědět, jaká práce je pro SPECTRE doopravdy relevantní a jaká ne, a proto nemůžeme pro ARM64+ACPI začleňovat cokoliv konkrétního, dokud nebudeme mít přístup ke skutečným specifikacím nebo dokud nedostaneme video od někoho s monoklem a kočkou v klíně, který by nám požadavky osvětlil.

-- Arnd Bergmann

Nástroj pro checkpoint/restore v1.0

Po letech práce je konečně dostupná verze 1.0 nástroje pro checkpoint/restore (kontrolní bod/obnovu). Jde převážně o nástroj postavený nad uživatelským prostorem, který dokáže uložit stav sady procesů do stálého úložiště a někdy v budoucnu jej obnovit, možná i na jiném systému. Více o aktuálním stavu této funkčnosti se dozvíte v tomto článku.

Facebook má rád Btrfs

Dva vývojáři Btrfs – Chris Mason a Josef Bacik – současně oznámili svůj přechod z Fusion IO do Facebooku. Chris k tomu říká: Z pohledu Btrfs se toho moc nemění. Všechny mé příspěvky do Btrfs zůstanou otevřené a nadále budu svou práci dělat v upstreamu. Josef k tomu dodává: Facebook usiluje o úspěch Btrfs, takže z pohledu mého zapojení v projektu se toho moc nezmění, nadále budu spravovat btrfs-next a pracovat na stabilitě.

Závěr začleňovacího okna 3.13

Dne 22. listopadu Linus vydal Linux 3.13-rc1 a uzavřel začleňovací okno 3.13, možná že o několik dnů dříve, než vývojáři čekali. Včetně několika opožděných commitů po -rc1 bylo v tomto vývojovém cyklu zařazeno nějakých 10 600 neslučovacích sad změn; to je přibližně 700 od souhrnu z minulého týdne.

Mezi nimi je jen několik významných změn viditelných uživatelům:

• Systém souborů squashfs nyní umí dekompresi ve více vláknech; dokáže také dekomprimovat přímo do cache stránek, čímž odstraňuje dočasný buffer, který byl používán dříve.
• V jaderném úložišti klíčů bylo uděláno několik změn. Maximální počet klíčů byl změněn na v podstatně neomezeně, což kódu NFS například umožňuje ukládat velké množství mapování uživatelských ID. Přibyl nový koncept „důvěryhodného“ klíče, který může být získán z hardwaru nebo jinak ověřen a klíčenky mohou být nastaveny tak, aby povolovaly jen důvěryhodné klíče. Nakonec byl přidán mechanismus persistentních klíčů nepřiřazených k uživatelskému ID a data klíčů mohou nyní být docela velká; obě tyto změny byly nutné pro to, aby Kerberos mohl používat subsystém klíčů.
• Podpora nového hardwaru.

Mezi změny viditelné vývojářům patří:

• Přibyla nová datová struktura asociativních polí. Byla přidána kvůli práci na klíčence, ale dá se používat i jinde. Více najdete v dokumentaci.
• Přibylo údajů v struct page po zařazení patche od Joonsoona Kima, který způsobuje, že tam alokátor slab uchovává více informací. Více se dozvíte v tomto článku.

Nyní může započnout stabilizace.

ACPI pro ARM?

ACPI nebylo v době prvního začlenění do jádra zjevnou předností. Standard byl nový, implementace nebyly spolehlivé a jeho podpora znamenala přidání velkého virtuálního stroje do jádra. Po celé roky bylo bootování s vypnutým ACPI první odpovědí na spoustu problémů; doteď se dá najít řada stránek, které toto čtenářům doporučují. ACPI si ale povětšinou získalo postavení povinné části standardu PC platformy. Teď to ale vypadá, že se podobný příběh odehraje ve světě ARM.

Argumenty pro a proti

Už několik let se šušká o tom, že by se ACPI mělo na ARM objevit, hlavně pak na serverových systémech. Nedávno se objevil jistý kód, který by takové systémy měl podporovat; Olof Johansson, jeden ze správců stromu arm-soc, se na kód podíval a nelíbil se mu:

Čím více vidím raného kódu pro UEFI/ACPI, tím jistější si jsem, že tyhle sračky v jádře nechceme. Věci jsou kvůli tomu znatelně zmatenější a zatímco se snažíme vše převést na DT – tak tuto snahu budeme přerušovat jen kvůli tomu, abychom přidali ještě více šablonovitého [boilerplate] kódu a celkovému postupu tak ublížíme.

V této a několika následujících zprávách Olof ujasnil, co se tím snažil říci. Svět ARM už má mechanismus pro popis hardwaru – stromy zařízení – a ten se teprve teď dostává na výsluní. Přidání podpory pro strom zařízení si vyžádalo změny ve spoustě ovladačů a kódu platforem; podpora ACPI by znamenala dvojnásob práce a druhou cestu v kódu pro konfiguraci v systému, která by musela být navždy udržována. Ještě horší pak je to, že pro ACPI v provedení ARM nejsou žádné zavedené standardy a nikdo neví, jak má co fungovat a to, co se objevuje v počátcích, není moc povzbuzující. Přidání podpory pro ARM ACPI by znamenalo zavázat se k podpoře pohybujícího se cíle donekonečna.

Olof pak navrhl, že by možná bylo nejlepší počkat, než ostatní přijdou na to, jak má ACPI na ARMu fungovat:

Ale moment, lidi, co tohle dělají už celá léta, tu vlastně máme. Microsoft. Oni by se za to měli postavit a vytrpět si to. Jakmile bude platforma připravená pro jejich potřeby, tak si to u sebe pořešíme. Konec konců, tohle na x86 zafungovalo docela dobře.

Dodal, že dokud se neobjeví systémy s ACPI a Windows a nebudou fungovat dobře, pak by se měla linuxová komunita držet od ACPI na ARMu daleko. Pokud by se systémy s ACPI opravdu dostaly na trh, pak by podle něj bylo možné je podporovat s vrstvou, která by před bootem přeložila systémové tabulky ACPI do formátu stromu zařízení.

Nesouhlas s tímto postojem se objevil v několika podobách. Několik lidí poukázalo na to, že standardy vyvinuté Microsoftem nemusí linuxové komunitě vyhovovat tak, jak bychom byli rádi. Takto to vyjádřil Mark Rutland (správce vazeb stromu zařízení):

Nejsem si jistý, že je úplně rozumné předpokládat, že se do toho vloží Microsoft a vyvine standardy, které pro nás budou užitečné nebo třeba jen použitelné na většině systémů, které mohou existovat. Pokud se do toho vloží, pak my (na základě předpokladu, že Linux by měl běžet všude tam, kde může běžet jiný OS) budeme muset podporovat všechny standardy, co vytvoří.

Russell Kind přidal další připomínku, kterou mnoho lidí opakovalo: odmítnout podporu ACPI by komunitu připravilo o možnost ovládat (nebo dokonce řídit) rozvoj standardu. Jeho slovy:

Máme možnost definovat, jak chceme, aby ACPI vypadalo: máme možnost mít vlastnosti (properties) v ACPI, které budou používat stejné názvy, jako máme v DT (stromu zařízení).

Postavit se k ACPI zády by podle Russella bylo rozhodnutím, kterého by komunita z dlouhodobého hlediska litovala.

K diskuzi se připojil Jon Masters a prohlásil, že servery na bázi ARM půjdou cestou ACPI, slovy všichni velcí hráči budou ACPI používat, ať se vám to líbí, nebo ne. Řekl, že oblast serverů potřebuje standardizovaný a pevný standard, a podle něj je abstrakce ve stromu zařízení příliš nestabilní, aby byla použitelná (což je tvrzení, proti kterému se Grant Likely silně ohradil). Red Hat podle Jona plně stojí za ACPI na serverech ARM ve všech produktech, o kterých nikdy neřeklo, že je bude kdy nabízet. Jonovo vyjádření, které napovídá, že vše už bylo v konferenčkách pod zámkem NDA rozhodnuto, mu na jeho stranu nezískalo mnoho fanoušků, ale jeho postoj zůstává stejný: systémy s ACPI se na trhu objeví a Linux se s nimi musí nějak poprat.

Co s tím

To ale pořád neodpovídá na otázku, jak se s nimi poprat. Arnd Bergman naznačil, že ACPI nemusí pro komunitu ARM představovat dlouhodobý problém:

Myslím si, že stále můžeme ACPI na ARM64 považovat za začátečnickou chybu a pro několik systémů, které se s tím budou dodávat, můžeme poskytnout ručně napsané bloby s DT. Hlavním důvodem to tak udělat bylo očekávané množství serverů s Windows RT, ale WinRT se teď moc dobře nedaří, takže není úplně mimo očekávat, že to dopadne jako tablety s WinRT.

Mnoho lidí si ale myslí, že ACPI by nevymizelo, takže komunita bude muset přijít na způsob, jak se s ním vypořádat.

Jednou možností by mohl být Olofův nápad překládat tabulky ACPI do stromu zařízení, ale tento postup si nezískal příznivce. Mnoho lidí jej považuje za řešení problůmu, které povede k nekončícím problémům; je tu také problém s během kódu v ACPI Machine Language (AML), který se nachází ve firmwaru ACPI. AML může být nezbytné pro inicializaci hardwaru a správu výkonu, ale nemá obdobu ve stromech zařízení. Obecně byla nálada taková, že pokud má být ACPI na systémech ARM podporováno, pak by mělo být podporováno řádně a ne za nějakou překladovou vrstvou.

Z krátkodobého hlediska ale nějaký překlad do stromu zařízení – buď při bootu nebo ručně – bude asi výsledkem. Přidání kódu pro podporu systémů s ACPI, co se mohou v blízké době objevit, může řadě lidí připadat jako dlouhotrvající břemeno kvůli krátkodobě existujícím systémům. Věci by mohly změnit systémy, které podle popisu Arnda jsou PC bez CPU s x86 a s čipem ARM místo něj; přidání podpory ACPI pro takové stroje by podle jeho slov bylo dostatečně neškodné. Vypadá to ale, že Arnd je silně proti přidání podpory ACPI pro komplikované systémy ve stylu ARM.

Z dlouhodobějšího hlediska je pravděpodobné, že komunita bude sledovat situaci a vyčkávat. Bude probíhat úsilí o řízení rozvoje ACPI pro systémy ARM; zejména Linaro pak má vývojáře, jež jsou do tohoto procesu zapojeni. A i Olof je otevřen přidání podpory pro ACPI někdy v budoucnu, jakmile jeho příznivci se na tom už nějak shodli, vyřešili své vrtochy a dali dohromady použitelnou stabilní platformu. To ale podle něj může trvat roky.

Microsoft díky své dominanci na trohu softwaru pro systémy typu PC mohl protlačit hardwarové standardy, jakkoliv se mu zlíbilo. Ve světě ARMu má Linux stejně silné postavení, takže by bylo trochu překvapivé být v postavení toho, kdo někoho dohání. Částí problému je ovšem to, že za Linuxem nestojí jediný silný hlas, který by jej zastupoval u stolu, kde se plánují standardy; firmy jako Linaro a Red Hat tento problém řeší, ale určitě nezastupují nebo ani zdánlivě nemluví na toto téma se zbytkem komunity. Skutečnost, že tato práce probíhá pod dohodou o mlčenlivosti (NDA), tomu moc nepomáhá; NDA nejde moc dohromady s tím, jak komunitní vývoj probíhá.

Nakonec se to ale jistě vyřeší; je obtížné si představit úspěch jakéhokoliv hardwaru na bázi ARM bez řádné podpory v Linuxu. Je to hlavně otázkou, jak mnoho kráto a dlouhodobých obtíží bude potřeba snést, aby přišla podpora na svět. Po porodních bolestech se ACPI ve světě x86 povětšinou vyřešilo; možná se mu dostane užitečného postavení i na trhu s ARM.

Diskuse k tomuto článku

[chlap]

" Olof pak navrhl, že by možná bylo nejlepší počkat, než ostatní přijdou na to, jak má ACPI na ARMu fungovat:

Ale moment, lidi, co tohle dělají už celá léta, tu vlastně máme. Microsoft. Oni by se za to měli postavit a vytrpět si to. Jakmile bude platforma připravená pro jejich potřeby, tak si to u sebe pořešíme. Konec konců, tohle na x86 zafungovalo docela dobře. "

Na linuxu porad breci(me), ze MS ma dominantni postaveni, prijde uz roku linuxu,... Na ARMu a mobilnich platformach linux vladne, tak je potreba se k tomu postavit celem. Rozhodnout bud ano, ACPI chceme, udelejte ho takhle a takhle, protoze to se nam hodi. Nebo ho nechceme, protoze mame sve jine reseni (DT), a pak je potreba se stavet proti tomu standardu.

Rozhodne ne vsak rict "pockame, co udela Microsoft", tvarit si lisacky a za par let brecet, ze ARM-ACPI jde na ruku MS a linux to musi vohackovavat.

[ed]

Ono hlavne riesenie uz existuje, len sa nanho nejako pozabudlo. Presne na taketo veci bol kedysi v dobach drevnych vyvinuty OpenFirmware. Je to platform agnostic, nema to problem s podporou 32 ani 64 bitovych strojov, CISC ani RISC, little endian ani big endian (afaik niektore OpenBIOSy pre PC su tiez len layerom nad OpenFirmware), jeho opensourcova implementacia existuje, takze by to nebolo treba pisat od piky a implementacia OF v kerneli tiez. Vieme z toho priamo bootovat a ma to svoju vlastnu strukturu pre popis stroja.

Navyse s OF by sa zabila aj druha mucha, totiz ze do ARM netreba tahat mega zvrhle EFI, ktore mne pripada len ako viac alebo menej klonovany OF, aby si Intel mohol dat ciarku, ze aha, priniesli sme novy standard.

[Grunt]

To ACPi až tak neštvě (ostatně je to standard), ale co tam zas sakra dělá to UEFI? Na ARMu? No to nech jdou do prdele.

[pavlix]

Tady si zas někdo plete Linux s firmou.

[Sten]

Vždyť přesně to Olof říká: ACPI nechceme, máme DT, ale pokud ho tam cpát opravdu chcete, tak nám napřed ukažte fungující implementaci, my se s tím potom nějak popereme.

[stativ]

Což je může být chyba, protože takhle vývojářům HW dávají zcela volnou ruku. Teď ještě mají možnost jim do toho kecat a případně zasáhnout, když budou chtít udělat nějakou kravinu.

[pc2005]

DT je ale jen stromový seznam hardware. ACPI poskytuje i funkce, které jdou volat. Ekvivalent by byl třeba uboot, který by se rozšířil o volatelné funkce. Problém je hlavně v tom, že ty ARM servery budou mít nejspíš vysoce sofistikovaný firmware (vzdálený přístup ještě bez OS, diagnostika šitá na HW...) a závislost inicializace hw na čistě kernelu bude nežádoucí (samotný DT tedy nestačí).

[martian]

Jon's wording, along with his suggestion that everything has already been decided in NDA-protected conference rooms, won him few friends in this discussion

Toto by som prelozil "..., mu neziskalo vela priatelov" co aj bude v kontexte davat nejaky zmysel...

[petr_p]

Já bych řekl, že je to přeložené přesně stejně ironicky.

[martian]

Obavam sa, ze sa jedna o idiom. Skus vyhladavac a porovnaj si clanky obsahujuce "win few friends" vs. "win a few friends". Aj ked uznavam, ze tie dve vety, su celkom pekny prekladatelsky hlavolam - hlavne to s tymi nepodporovanymi produktmi co nespomenul.

Keby som uz chcel byt ironicky, tak by som to prelozil, ze mu to ziskalo vela priatelov.

A aby som neprznil jazyk, ako by nestacilo, ze nepouzivam makcene a dlzne, tak by som napisal mnoho

[Luboš Doležel (Doli)]

To není idiom, few zkrátka znamená málo. V textu jsem to vyjasnil/opravil.

[petr_p]

„few“ znamená „řada“, „spusta“. „A few“ znamená „několik“, „málo„. Původní překlad byl správně.

[pavlix]

„few“ znamená „řada“, „spusta“

ORLY?

[jehovista]

quite a few. Vzdycky zalezi na kontextu

[frr]

"Quite a few" znamená doslova "pěkných pár".

[frr]

Už to naznačili ostatní. "A few" znamená "několik", "pár", ale v pozitivním slova smyslu. "Few" bez členu znamená málo, s negativním nádechem - pokud je to použito v ironickém kontextu (zrovna tenhle případ) tak to znamená "těžko si tím získal nějaké přátele". Přeloženo volněji je to eufemismus pro "všechny si nás hned na začátku naštval". Rozdíl mezi "few" a "a few" vyžaduje od čtenáře postřeh zejména ve složitější větné skladbě.

[ovoce]

Přesně tak, v tomhle případě to rozhodně znamená "mu získalo jen málo/pramálo kámošů", a to docela explicitně.

[...]

materialni vychova se pozna na tisic mil ty negativni nadechu.

[...]

kdyz uz se vytratilo "mene je nekdy vice" tak bude potreba zrejme protipriklad... je lepsi mit zachod s jednim beznym kusem vykalu nebo mit zachod nesplachnutelny a pretekajici temito vykaly?

[Jerry12]

To mi trochu pripomina jednu hlasku ze zivota: "Lepsi h***o v hrsti, nez sr***y na hlave ..."

[Petr Ježek]

Mne zajímá především to, zda dojde k degradaci rychlosti a pokud ano, tak proč.