Naskriptujme si kernel

8.5.2006 23:26 | Přečteno: 1295×

Tak mě napadlo (poté, co jsem dumal nad ovladači pro WiFi a vyslechl přednášku o OpenFirmwaru - ahoj, Aničko, opravdu se mi líbila), proč vlastně nepřidat do kernelu malý interpret nějakého bytekódu v duchu Forthu?

Jistě se ptáte, k čemu by to bylo dobré (tedy kromě duševního cvičení).

Správná otázka. Nuže: Na drivery. Zejména na ty, které nejsou součástí základního jádra.

Kdyby se totiž driver napsal v bytekódu, který by měl předem dané a známé instrukce, vyřešil by se tím problém proměnlivosti vnitřních struktur jádra. Autor driveru by se prostě s těmito strukturami a voláními vůbec nezabýval, to by za něj udělal interpreter bytekódu. Pokaždé, když by se tyto vnitřní věci změnily, patřičně by se upravily vnitřnosti interpreteru, instrukce by ale zůstaly stejné a drivery by fungovaly beze změn.

Co práce a nervů by se ušetřilo - zvlášť pro autory externích kernelových modulů... Možná i výrobci hardwaru by byli ochotnější dodávat drivery pro Linux, kdyby věděli, že to nebudou muset přepisovat s každou další verzí kernelu.

Co na to říkáte? Je to geniální myšlenka, nebo úplná pitomost?

Přinejmenším jeden argument proti už mám: Kolega, kterému jsem se s tímto nápadem svěřil, zastává názor, že by to bylo příliš pomalé. To je bohužel velmi platná připomínka, ale doufám, že přinejmenším u určité skupiny driverů, například taková Wifi, by to nevadilo.

       

Komentáře

[Kyosuke]

Proč pitomost? Forth nemusí být nijak extra pomalý, jeho bajtkód nedělá nic moc extra složitého a techniky threaded kódu jsou docela vypracované. Navíc i zde asi dost podstatnou část času nebude VM trávit v high-level slovech. Je to příjemně kompaktní věc, do jádra není špatná a není tam moc prostoru pro bugy.

[Miloslav Ponkrác]

Jinak řečeno, je to jen jinak zakuklený požadavek na HAL - hardwarovou abstrakční vrstvu.

Ale upřímně, pokud by měly být ovladače realizovány pomocí byte kódu, a tedy tím celý systém zpomalován, tedy jinak řečeno pokud autor souhlasí s obětováním malé části výkonu na modularitu a stabilní API, pak hlasuji raději pro mikrojádrový systém, který svojí modularitou určitě dokáže větší zázraky.

[Kyosuke]

Dobrý mikrojádro by byl výbornej počin. Ale mám pocit, že zrovna praktický výkon takových systémů taky docela kulhá, takže nevím, jak argument výkonu obstojí. Třeba jendou někdo na něco přijde, já v tomto oboru vzdělán nejsem.

[Miloslav Ponkrác]

No, s tou rychlostí to asi nebude až takový problém. Mac OS je mikrojádrový a pomalý snad není. Mám pocit, že Amiga OS je taky blízká mikrojádru, a když jsem jí tehdy testoval - procesor na 12 MHz, 0,5 MB paměti, grafické prostředí - pomalá se nezdála. Co QNX? Kdysi jsem testoval disketu - 1,44 MB, kde bylo QNX s celým grafickým prostředím, několika grafickými aplikacemi včetně webového serveru s podporou kaskádových stylů a JavaScriptu. Velmi svižně to jelo a dodnes nechápu jak je možné celý systém i s grafickým prostředím nacpat na jednu disketu. V tom grafickém prostředí bylo i kompletní grafické nastavení celého hw a připojení k internetu. A v neposlední řadě mám vedle sebe mobilní telefon Nokii, ve které běží mikrojádrový operační systém. A jen tak mimochodem, architektura jádra Windows se začíná velmi až nebezpečně podobat mikrojádru.

Podle mě pomalost mikrojádra je blbost. Mikrojádrové systémy jsou nejspíš principiálně pomalejší, než makrojádrové, ale to neznamená, že jsou pomalé.

[Kyosuke]

Mac OS X je mikrojádrový? To je pro mě novinka, myslel, že je to monolitický BSD kernel nad mikrojádrem, z jakéhodi pochybného důvodu. A neproběhla tu nedávno zprávička výkonnostních problémech Xnu? QNX je jiný kafe, na ten bych se rád podíval. To se jim opravdu povedlo, ten beru.

[Miloslav Ponkrác]

Mac OS není asi dobrý příklad. Nicméně svižné, dobře navržené a funkční mikrojádrové systémy existují.

[anicka]

OS X ma z BSD jenom network stack a par dalsich drobnosti. Kdyz se rekne Darwin a mysli se kernel OS X, zrejme se mluvi o trojici Mach (mikrojadro), BSD casti a I/O kitu.

Osobne mam nejvic namitek proti tomu tretimu, psat device drivery v orezanem C++ je celkem za trest.

[Bluebear]

O mikrojádrech bohužel skoro nic nevím, ale nejsem proti, jen si myslím, že předělat linuxový kernel na mikrojádro by asi stálo hodně práce a času (hádám, že by se muselo přepsat nebo aspoň upravit skoro všechno).

Interpreter bytekódu by byl jednodušší na naprogramování v tom smyslu, že to může být jenom jeden samostatný modul, v jádře samotném by se nemuselo nic měnit.

[anicka]

Spis by to chtelo nakopat vyvojare Hurdu, aby trochu hnuli zadkem. Po tech patnacti nebo kolika letech by z nich uz konecne neco mohlo vypadnout ;o)

[Václav HFechs Švirga]

Na experimentování s mikrojádrem máme HURD, tak ať Linusův kernel zůstane hezky tak jak je, ale ten nápad s interpretem nevypadá špatně. Mít více možností nemusí být na škodu.

Jinak upozorňuji, že v problematice se neorientuji ;).

[Václav HFechs Švirga]

Hehe, Anička mě predběhla, měl bych více refreshovat ;). Jinak s ní souhlasím, o HURDU se zatím jedině občas promluví... černá magie pro zasvědcené je to! ;)

[Filip Jirsák]

Je tohle opravdu problém externích ovladačů? Myslím, že ovladač je potřeba někdy znova překompilovat (změna ABI), ale to si udělá každý při kompilaci jádra. Takže autora ovladače to neobtěžuje, nic nemusí měnit. Kdy musí autor ovladače něco udělat je změna API jádra, a ta by se stejně promítla i do onoho bytekódu (leda že by onen interpret emuloval staré API – změny v API jádra snad ale většinou nebývají náhlé, že by se v jedné verzi objevilo nové API a staré tam už nebylo, a udržovat onu emulaci po delší dobu by myslím bylo kontraproduktivní).

[miso]

ale to si udělá každý při kompilaci jádra. Takže autora ovladače to neobtěžuje, nic nemusí měnit.

S vynimkou closed source driverov, o ktorych je rec

[Bluebear]

Ano, měl jsem na mysli především closed source drivery, ale stejný problém je i s open sourcovými moduly, pokud nejsou součástí hlavního stromu.

[Bluebear]

Vtip je v tom, že změna API by se projevila uvnitř interpreteru bytekódu, ale ne navenek - bytekód samotný by zůstal stejný, takže by se už nemuselo předělávat nic dalšího, drivery běžící nad ním by mohly zůstat beze změny.

Velké změny API náhlé nejsou, naopak jsou dopředu ohlášeny, v tom si vývojáři jádra počínají velmi dobře a zodpovědně. Potíž je v tom, že i úplně malá změna (často oprava chyby), kterou všichni považují za naprosto nevinnou, takže ji ani moc neohlašují, může v nějakém driveru způsobit katastrofu (klasický příklad jsou proprietární grafické drivery - jedna drobnost a už to letí).

[anicka]

Ja bych mela jeste pripominku z jineho soudku. Implementace forthovske virtualni masiny neni IMHO napad vhodny okopirovani. Ten jazyk je dobry pro pocitace, ale priserny pro lidi. Udrzovani driveru napsanych ve Forthu musi byt silene. Ostatne soudim, ze proto jich je tak zoufale malo - koupit si nahodny PCI radic a zjistit, ze na nej existuje driver (a tedy z disku, ktery k nemu pripojime, muzeme s nasim PPC nebo SPARCem nabootovat), je skoro jako vyhrat v loterii ;o)

Jirko, dik za pochvalu, od tebe si ji moc vazim.

[Bluebear]

To je pravda, mínil jsem použít Forth jen jako assembler. Nad ním by bylo možné postavit nějaký jednoduchý kompilátor, který by překládal z C (nebo podobného jazyka) do toho bytekódu. To by ale neměl být velký problém, podobných kompilátorů už existuje hodně, stačilo by některý přiohnout (možná jen napsat jiný backend).

Ostatně... kdysi jsem něco psal v MUFu, což je vlastně taky jistý druh Forthu (aspoň myslím). Žádný komfort to pravda nebyl, ale šlo to, člověk si zvykne i na šibenici

[Kyosuke]

No, Forth se musí umět. Thinking Forth je moc pěkná knížka, doporučuju (i kdyby jen kvůli myšlenkám a ne samotnému Forthu). Ale nemyslím, že by psaní ve Forthu bylo složitější než v assembleru, když to má člověk pěkně interaktivní a může si s tím vyhrát. Ostatně pro exploratorní programování ten jazyk vzniknul.

[anicka]

Takovy PPC assembler mi oproti Forthu prijde jako neobycejne prijemny a pohodlny nastroj. Presto bych v nem nechtela psat ovladace, kdyz je muzu napsat v cecku. Ale proti gustu...

[zde]

> proč vlastně nepřidat do kernelu malý interpret nějakého bytekódu

Třeba protože tam už jeden dynamický překladač bytekódu je, a je efektivně implementován v hardware? (x86 ISA -> ROPs).

Navíc netuším jak by mohla abstakce *KÓDU* odstínit od změn v datových strukturách. To je záležitost zavedení a dodržování (dnes neexistujícího) kernelového ABI, a ničeho jiného.

[Bluebear]

Třeba protože tam už jeden dynamický překladač bytekódu je, a je efektivně implementován v hardware? (x86 ISA -> ROPs).

O tom vůbec nevím, co dělá, takže k tomu to nemůžu nic říct...

Navíc netuším jak by mohla abstakce *KÓDU* odstínit od změn v datových strukturách.

Programátor v bytekódu nemusí přistupovat přímo na datové struktury v jádře, protože nepotřebuje volat funkce z jádra, která s nimi pracují. To místo něj dělají instrukce bytekódu a odpovídající data mu bytekód dodává dohodnutým, předem definovaným způsobem.

To je záležitost zavedení a dodržování (dnes neexistujícího) kernelového ABI, a ničeho jiného.

No jo, jenže zavedení jednotného kernelového ABI není v současné době reálné a má to kromě formálních i technické důvody, takže tudy cesta nevede, alespoň teď ne...

[zde]

> O tom vůbec nevím, co dělá, takže k tomu to nemůžu nic říct...

Tím jsem chtěl naznačit že všechny současné x86 procesory "interpretují" instrukce prostřednictvím dynamického překladu, tj "strojový kód" je fakticky v roli bytekódu, takže žádný nový bytecode zavádět nemusíme :)

> Programátor v bytekódu nemusí přistupovat přímo na datové struktury v jádře, protože nepotřebuje volat funkce z jádra, která s nimi pracují. To místo něj dělají instrukce bytekódu a odpovídající data mu bytekód dodává dohodnutým, předem definovaným způsobem.

Ten "dohodnutý způsob" odpovídá zmrazení binárního rozhraní do kernelu v určité verzi- to lze ale snadno realizovat i bez bytekódu, ten je pouze nadbytečný a nijak nepomůže. Např. pro každý struct lze přístup k jeho položkám buď ustálit na konstantních offsetech, nebo je zpřístupnit pomocí set_/get_ funkcí.

[Bluebear]

Ten "dohodnutý způsob" odpovídá zmrazení binárního rozhraní do kernelu v určité verzi- to lze ale snadno realizovat i bez bytekódu, ten je pouze nadbytečný a nijak nepomůže.

Myslím, že to není úplně pravda. Interpret bytekódu jako "tlumočník" mezi driverem a zbytkem jádra může provádět poměrně složité věci, které by se pomocí wrapper-funkcí dělaly špatně.

Hodně vykonstruovaný příklad: bytekód může umožnit, aby driver fungoval jako stavový stroj bez složitých callbacků. Například si představ instrukci "alokuj určitou oblast paměti/připrav nějaké zařízení a zavolej mi, až to bude hotovo", která se vykoná a hned se vrátí; interpret si něco chroustá v pozadí, zatímco bytekód normálně běží, a až je dokonáno, přesměruje se vykonávání bytekódu někam jinam.

Např. pro každý struct lze přístup k jeho položkám buď ustálit na konstantních offsetech, nebo je zpřístupnit pomocí set_/get_ funkcí.

Mám pocit, že konstantní offsety struktur by při dalším vývoji kernelu strašně překážely. Funkce set/get by asi šly, ale pochybuju, že by všechno šlo napasovat na tenhle model.

[Miloslav Ponkrác]

Co může realizovat byte kód navíc a nelze to realizovat wrapperem? Ten byte kód je tam prostě navíc ve stylu: "když už to má být složité, tak pořádně".

Kolega nade mnou má pravdu, nejde o nic jiného, než o zmrazení API, nebo chcete-li vytvoření konstantního API na určité abstrakční úrovni. Pod títo konstantním API musí být emulační vrstva, která to namapuje na skutečné API jádra. Jestli ta emulační vrstva má byte kód, je jen věcí implementace a IMHO právě teď je to jenom zbytečná komplikace.

Byte kód se vyplatí jen tehdy, pokud je abstrakce způsobená byte kódem natolik přínosná ve významném počtu případů, že se práce s vybudováním, implementováním, laděním a zejména údržbou celého virtuálnéího stroje vyplatí. Nejsem si jistý, jestli je tohle právě ten případ. Navíc každý virtuální stroj rovná se ztráta rychlosti a efektivity kódu, takže navíc by muselo nejspíš docházet ke složitých hackům a obcházení virtuálního stroje v případě, kdy je potřeba maximální rychlost a efektivita.

A použít Forth? Děkuji nechci. Nejsem masochista, opravdu ne.

A Java v jádře? Ještě horší!

Celé mi to vychází tak, že je jako abstrakční vrstva pro tyhle případ lépe použít mikrojádrový operační systém. Bude to efektivnější, výkonnější, rychlejší, lépe se to bude ladit, udržovat, apod.. Jen je potřeba si uvědomit, že Hurd není dobrý příklad jak se má dělat mikrojádrový systém, protože konečný termín Hurdu lze vyjádřit funkcí NOW()+1 rok, což platí už 15 let, a pokud se nic nezmění, bude platit i nadále.

Pokud už bych nějaké skriptování v jádře připustil, tak jediným vhodným kandidátem mi přijde Lisp. Ale raději bych neskroptoval v jádře nic.

[Filip Jirsák]

Navíc každý virtuální stroj rovná se ztráta rychlosti a efektivity kódu

Takhle obecně to asi nebude moc pravda, protože virtuální stroj mi umožňuje dělat dynamické optimalizace (když už ten cyklus prochází po 1000, tak si VM může říct, že by možná stálo za to vnitřek cyklu zoptimalizovat na rychlost), takže někdy může být virtuální stroj i rychlejší.

Nic to ale nemění na tom, že pro psaní ovladačů mi to přijde jako dost velký úlet. Nehledě na to, že napsat takový virtuální stroj, který by byl schopen usoudit "hele, teď paří Dooma, tak mu ten ovladač WiFi zoptimalizuju na Dooma", by bylo složitější než s pomocí reverzního inženýrství napsat opensource ovladače ke všem myslitelným čipsetům WiFi karet v klasickém C a udržovat jejich API

[Miloslav Ponkrác]

Ano a i dynamické optimalizace znamenají ztrátu výkonu a efektivity. Jednak se ty optimalizace dělají v čase běhu, tudíž zpomalují. A jednak pokud VM bude sledovat kolikrát cyklus prochází, tak to nelze udělat bez dalšího zpomalení toho cyklu samotného. Tudíž další zpomalení. Virtuální stroj za rovných podmínek nemůže být nikdy rychlejší. Veškeré testy a teorie, že virtuální stroj může být rychlejší vždy předpokládají chybu v efektivitě strojového kódu, či C/C++, nebo jiného jazyka. Je to stejné asi jako když si řeknu, že můžu běžet rychleji, než mistr světa v běhu, ale pouze za předpokladu, že tento má zlomenou nohu. Takže takto se dokazuje, že VM může běžet rychleji. Tedy nic jiného, než podvod.

S druhým odstavcem naprosto souhlasím.

[Filip Jirsák]

Předpokládáte, že je něco lépe optimalizované a něco hůře. Což ale není pravda – od jistého okamžiku každá optimalizace je vždy optimalizace něčeho nebo pro něco. Takže zatímco statická optimalizace v době kompilace/linkování mi vytvoří třeba kód pro základní instrukční sadu i386, dynamická optimalizace za běhu může zjistit, že procesor umí počítat rychle různé "multimediální instrukce" a použít příslušný kód. Množství využití takového kódu pak může dosáhnout hranice, za kterou už jsou náklady na onu dynamickou optimalizaci nižší, než je výsledný efekt optimalizace, tj. program s touto optimalizací bude v takovém případě rychlejší než ten s optimalizací v době překladu.

Do jisté míry je to podvod, protože teoreticky je možné onu optimalizaci udělat předem. Jenže to pak znamená mít optimalizované binárky pro všechny možné architektury a dokonce i pro různé způsoby využití. A ona neoptimálnost se přesune pro změnu na uživatele, který se bude muset rozhodovat, zda chce vim optimalizovaný pro dlouhé řádky nebo kontrolu pravopisu (třeba). Čímž stráví nesrovnatelně víc času, než vim prováděním algoritmu optimalizovaného pro krátké řádky nad jedním dlouhý řádkem.

V praxi ony rovné podmínky nastávají jen zřídka kdy (nejlépe nějaké bechmarky ), takže ve výsledku se po tom nejrychlejším sprinterovi taky někdy chce, aby plaval nebo jel na kole, a tam už opravdu může být někdo jiný rychlejší

Jestli se nepletu, jsou už teď v linuxovém jádře vlastně dynamické optimalizace např. ve virtual memory subsystému (VM se snaží chovat jinak, pokud má málo paměti než když jí má habakuk), optimalizace zde ale není řešena bytekódem a samostatnou virtual machine, ale pouze jistou virtualizací samotného C kódu. Někdo, kdo sleduje vývoj kernelu víc než "jen" z Jaderných novin mne snad doplní, upraví nebo rovnou popraví

[Miloslav Ponkrác]

Moment, já jsem nikdy nepředpokládal, že existuje něco jiného, než optimalizace na nějakou optimalizační funkci. Moje teze je jednoduchá, je-li možné optimalizaci provést staticky, je lepší jí provést staticky a výsledky jsou obvykle lepší. Lze-li tedy takovou statickou optimalizaci provést, je dynamická optimalizace méně efektivní (předpokládejme optimalizační kritérium = rychlost).

Zrovna u jádra Linuxu argumentovat tím, že překlad pro danou architekturu lze snadno udělat kompilátorem.

Co se týká dynamických optimalizací, pořád je optimálnější naprogramovat to staticky s přesně danými alternativami, než použít univerzální virtuální mašinu. (Mějte pořád na paměti zvolené optimalimalizační kritérium = rychlost běhu).

[machr]

taky me napadl super napad. prepiseme cely jadro do pythonu. joooooooooo, to bude coooooooooooooooool !!!!!!!!!!!! sice to bude asi tak 397x pomalejsi nez v C, ale koho to dneska zajima... ;)