Názory k článku HelenOS nikdy nebude dokončený, říká jeho autor Jakub Jermář

A co takhle ten havarovaný modul zresetovat?

Ano, tohle je něco, co třeba lidé kolem MINIXu uvádějí jako univerzální všelék a opakují to téměř jako svou mantru :)

Samozřejmě restart spadlého serveru může krátkodobě pomoci, ale problém to ve skutečnosti neodstraní. Pokud je třeba ve VFS serveru nějaká chyba nebo neošetřený stav, tak je velmi pravděpodobné, že se po restartu projeví znovu — dříve či později.

V současné době v HelenOSu tedy spadlé servery nerestartujeme, i když jsme o tom už párkrát uvažovali alespoň jako o jakémsi prostředku poslední záchrany (potřebovali bychom k tomu zřejmě nějaký session manager, který zatím nemáme).

Chceme, aby VFS ani jiný esenciálně důležitý systémový server prostě nepadal, a toho se snažíme dosáhnout jak kvalitním kódem a správným "softwarově-inženýrským" přístupem, tak různými pokusy o formální verifikaci správnosti kódu.

>> různými pokusy o formální verifikaci správnosti kódu.

Můžeš se o tom trochu rozepsat (nebo odkázat na nějaké vaše texty)?

Stav asi před rokem jsem popsal v tomto článku:

Martin Děcký: A Road to a Formally Verified General-Purpose Operating System, in Proceeding of the 1st International Symposium on Architecting Critical Systems (federated with CompArch 2010), LNCS 6150, Jun 2010

Aktuálně pracujeme na dvou dalších článcích s konkrétními výsledky. Vše je samozřejmě stále work-in-progress, ostatně jako celý HelenOS :)

Obavam se ze pokud bude projekt psan v C/C++, tak "pokusy o formalni verifikaci spravnosti kodu" zustanou jenom pokusy

Problém není v programovacím jazyku, ale v množství abstrakce a sémantické informace, která je v kódu nějak implicitně nebo explicitně obsažena. Souhlasim, že lze asi s jistou básnickou licencí obecně říci, že Java se verifikuje snadněji než C a funkcionální jazyky se verifikuji snadnějí než imperativní jazyky, ale v praxi jde vždy o to, jaké vlastnosti a jakým způsobem chcete verifikovat, jak se poperete s nerozhodnutelností a state space explosion apod.

Nástroje pro formální verifikaci céčka existuji, např. Frama-C, VCC.

Neuvazovali jste treba o nejakem kulturnejsim (rekneme funkcionalnim) jazyku?

Nevidím na céčku nic nekulturního. Každý programovací jazyk lze používat kulturním i nekulturním způsobem.

Ovšem budoucímu použití nějakého funkcionálního jazyka nebo alespoň imperativního jazyka s funkcionálními prvky (typu Groovy) se rozhodně nebráníme. Až budeme umět chodit, můžeme se učit běhat :)

To mi přijde jako pevná víra ve widlí filosofii. Autoři HelenOSu viditelně aspirují na kvalitu místo kvantity. Restart služeb třetí strany ostatně nevyloučili, pouze se snaží maximálně odladit životně důležité části svého systému.

Proč výrobci v poslední době tak moc o ty mikrokernely stojí?

Minix, Hurd i HelenOS jsou salónní teoretické projekty, u kterých není drajv na nasazení od praxe. Autoři si s tím hračičkují, miliskují se, ale prioritou není praktické nasazení a snaha to rychle prakticky co nejdříve nasadit.

Naproti tomu existuje řada skutečných mikrokernelových systémů. Leckde je to i nezbytné z důvodu spolehlivosti, kterou takový systém může nabídnout. PLus řadu dalších vlastností.

Ale Linus jednou řekl, že mikrokernel je blbost, tak prostě je. A všichni budou tvrdit jak je špatný, protože to řekl Linus. Jiný důvod není.

>>winNT architektura je v podstate mikrokernel

Slůvko .reloc v mých 344 ovladačích v adresáři Drivers říká něco jiného.
NT nesplňuje žádné z kritérií pro mikrokernel. Zkuste nějaké jmenovat.
P.S. Že to řekl Balmer s vyplazeným jazykem se nepočítá. XD

NT jádro obsahuje:
• Podporované FS, na kteých smí být OS, vč. práv
• Podporované způsoby rozdělení disku (MBR, GPT)
• Kompletní práci s registrem
• Uspávací režimy včetně obcházení errat některého HW
• Ad-hoc rozhraní pro některé důležité ovladače (pci, ntfs, tcpip...) - falešná modularita

Problém mikrojádra je výkon. Přepínání mezi procesy a přiřazování stránek paměti je zátěž. Dokud jsou jen desítky user procesů a celý systém jede v reálu, výkon je v pohodě a systém je tak výkonný, jak ho všichni známe. Ale jakmile se masově nasadí user-space na všechno, tak najednou poběží tisíce, ne-li desetitisíce modůlů, každý s vlastním adresním prostorem. X86 podporuje hardwarově jen 128 procesů, nepletu-li se, při vyšším počtu musí OS vyměňovat položky v tabulce procesů s těmi uloženými jinde. S takovou superzátěží může systém masově užívající user-space zapomenout na výkonnou síť, editaci hudby a vlastně na celé komerční využití. Vždyť i ta fréza se zláme o sklíčidlo dřív, než mikrojádro ráčí přesypat 4000 služeb, jak si možná žádá plánovač, a popoběhnout s naší aplikací. (Tady trochu přeháním, systém můžeme ořezat o grafické rozhraní, vypnout si na chvíli přerušení a je to :-)
Jedině že by se věc vydala cestou posunu kompromisu od efektivních k vysokoúrovňovým jazykům a v budoucnu získaný výkon procesorů se investoval do spolehlivosti systému.

X86 podporuje hardwarově jen 128 procesů, nepletu-li se, při vyšším počtu musí OS vyměňovat položky v tabulce procesů s těmi uloženými jinde.

Předpokládám, že tady hovoříte o Task State Segmentu. Ten má ovšem velikost 8192 položek a většina operačních systémů (včetně Linuxu a Windows) jej stejně nepoužívá pro přepínání vláken — používají klasický softwarový context switch.

Samozřejmě na x86 nejde TSS úplně vypnout (stejně jako segmentace), takže jedna položka v TSS tabulce je skutečně vždy vyplněna, ale po celou dobu běhu Linuxu, Windows i HelenOSu zůstává konstantní. Většina jiných platforem (včetně x86-64) žádnou analogii TSS nemá.

BTW: Nemyslím si, že existuje důvod, aby počet modulů/úloh v mikrojádrovém systému, který provádí několik činností (dejme tomu workload typického desktopu), rostl k tisícům. Už v žádném případě není důvod, aby mikrojádrový systém, který řídí frézu, měl 4000 modulů. Chápu argumentaci přehánením, ale ani s přeháněním by se to nemělo přehánet :-D

Servery v mikrojádrovém systému nemají granularitu tříd, ani nereprezentují jednotlivé instance objektů. Dovedu si představit mnohaprocesorový stroj vyřizující stovky požadavků na sekundu, na kterém budou běžet tisíce serverových úloh. Takové konfigurace dnes ale běží i nad monolitickými systémy.

Závěrem: Určitě nelze zpochybňovat overhead mikrojádrové architektury, ale také by se neměla démonizovat. Není to daň jen tak za nic. Je to daň za explicitní zachycení architektury systému v jeho kódu, vzájemnou izolaci komponent, kompozici složitého systému z jednoduchých stavebních kamenů apod.

Díky za upřesnění, samozřejmě souhlasím, x86-64 TSS má i v 64-bitovém módu. Ale už se skutečně nedá použít pro context switch jako v případě 16-bitové a 32-bitové varianty. O to myslím šlo v předchozí debatě, před více než 2 lety :)

ani som nevedel, že niečo také existuje. veľa ľudí robí dobrú robotu a pritom o nich málokto ie. Projektu HelenOS a každému, čo sa do toho zapojí, prajem veľa úspechov.

Jakube, jestli to tady budeš číst, můžu se zeptat, co tě vedlo ke startování nového projektu na zelené louce? Nezvažoval jsi zapojit se do Hurdu?

(hodně respektuju lidi, kteří mají drajv pustit se do něčeho obtížného i bez vidiny nějakého bezprostředního zisku, ale přijde mi, že pod Hurdem by mohlo být stejný množství srandy s větší šancí na praktickou využitelnost investovaného úsilí...)

>> nechtějí Hurd vydat do té doby, dokud nebude úplně hotový, dokonalý a nebude plnohodnotnou náhradou linuxového jádra

A není to prostě proto, že Hurd ještě na vydání není zralý? (nevím, ptám se)

Nechci rozhodně mluvit za Jakuba Jermáře, ale z mého pohledu vidím asi tak tři důvody, proč pracujeme na vlastním mikrojádrovém OS.

Tak to prostě začalo: Jak už říkal Jakub v rozhovoru, původní kořeny HelenOSu jsou v jeho školních zápočťácích a projektech. I pro nás ostatní to vždy bylo "learning by doing" a to jde podle mě rozhodně lépe, když člověk pracuje vlastním tempem na vlastním projektu, než když se musí zapojovat do práce "cizí" komunity. Aniž bych měl něco proti zapojování se do rozjetých projektů, je asi lepší, když to člověk dělá už jako zkušený programátor.

Historické souvislosti: Před pár lety se Hurd zmítal v dilematu, zda má být postaven nad Machem nebo L4, a byl rozhodně ještě méně použitelný než nyní. O MINIXu se pro změnu ještě před pár lety hovořilo jen jako o "tom výukovém operačním systému z knihy Andyho Tanenbauma", jako plnohodnotný OS ožil až s příchodem verze 3.

Vlastní design: Pár lidí z HelenOS týmu si myslí, že design Hurdu je příliš deformován potřebou být "UNIX compliant" a fungovat jako drop-in náhrada Linuxu nebo BSD kernelu v rámci GNU. Podobně se nám nelibí některá konkrétní rozhodnutí v MINIXu. V případě L4 některé z nás zase odrazuje ne přiliš hezký zdrojový kód.

Zkrátka chceme dělat věci po svém a tak, jak si myslíme, že to je správně. Jestli je to dobrá cesta, to ukáže čas :)

Díky za odpověď a přeju hodně srandy a úspěchů :)

Když jsme si s Jakubem povídali, tak i na to přišla řeč. Nakonec to ale v rozhovoru není. Důvodem pro vlastní projekt prý bylo především to, že chtěl mít vlastní výtvor, který má plně pod kontrolou a může ho směřovat tam, kam bude sám chtít.

Děkuju.

Stejně mi to ale přijde trochu zvláštní, mít projekt, který sice můžu směřovat, kam chci, ale který funguje daleko hůř (předpokládám) než jiný podobný už existující projekt...

Chápu to (a sám dělám) u věcí, kde ten projekt můžu poměrně rychle dostat do stádia funkčnosti ve všech pro mě podstatných oblastech, ale u takového molochu jako je jádro OS...

Nicméně určitě je mi to daleko sympatičtější než vytváření tisícé první "originální" distribuce Linuxu :)

to je podľa mňa len dobre. totiž, je fajn zaradiť sa do nejakého projektu, dostať nejaké to čísielko a enjakú oblasť na starosti - no dobré je tiež niečo viesť a riadiť, kam sa to bude uberať.

dobrý príklad je ubuntu, ktoré niekde ide. veľa ľudí s tým súhlasí a používa ho, iné skupiny si myslia, že by to malo ísť iným smerom. a keďže môžu viesť projekt aspoň čiastočne vlastnou cestou, tak to aj robia.

pri všetkých tých malých projektoch (myslím teraz veľkost v KB/MB, nie v počte ľudí) je dôležitá špecializácia. no a ak to ide iným smerom, ako by sa malo ísť, tak to niekto forkne, laebo začne robiť niečo podobné na zelenej lúke.

ReactOS jsem zkoušel asi před dvěma roky a bylo to úplně tragicky nestabilní. (Což je škoda, protože svobodná reimplementace WinXP by byla bomba)

Beru to, ze je to spis forek - ale jen pro orientaci - soucasny kernely maji uz skoro vsechno v modulech, ne? Jakej je rozdil mezi modulama a mikrokernelem?
PS. na me je to technicke docela akorat...fakt, je ze bych jeste snesl nejakou dalsi technickou informaci

Jakej je rozdil mezi modulama a mikrokernelem?

Moduly beží v kernelovém režimu CPU a ve společném adresovém prostoru se zbytkem kernelu. V mikrokernelu beží v kernelovém režimu mnohem méně kódu, "moduly" jsou od sebe vzájemně odděleny v samostatných adresových prostorech, komunikují pouze pomocí dobře definovaných rozhraní a běží v uživatelském režimu.

Výhod a nevýhod obou přístupů je mnoho — jako v mnoha jiných případech se ani tady nedá univerzálně rozhodnout, co je obecně lepší a co je obecně horší přístup. Pokud se s tím někdo dosud nesetkal třeba na nějaké přednášce o principech operačních systémů, lze určitě začít třeba články na Wikipedii.

Na druhou stranu to má svoji režii a psát událostní smyčky na každé volání služby je otrava. Mám dojem, že se to chtělo řešit nějakou standardní knihovnou, která by programátorovi aplikace ušetřila prsty.

Základní smyčku událostí (rozskok podle čísla metody) je stále nutné v HelenOSu psát ručně, i když již delší dobu uvažujeme o tom, jak tenhle boilerplate kód generovat automaticky. Stay tuned .. :)

Na druhou stranu, pro složitější komunikaci (kdy se komunikační protokol mezi klientem a serverem sestává z více atomických zpráv) není nutné vracet se do té top-level smyčky událostí, ale lze psát kód, který díky našemu IPC frameworku vypadá v podstatě standardně sekvenčně, ale přesto funguje asynchronně.

Ahoj,
dik za velmi zajimavy rozhovor z tyhle problematiky, ktera je mi uplne cizi, ale o to vic me zajima.
Cili jestli to chapu, hurd je taky typu mikrokernel a mam dojem, ze je ho mozny skloubit v ramci debianu 5 s gnu obalem. Je tohle taky cesta pro helenos? Najdeme dalsi debian s helenos? Zkusil tady nekdo nasadit hurd v debianu? Proc? :)
dik

A odvozeně též kromě Mac OS X i megaúspěšné iOS? (no flame)

>> V MAC OS X je použit XNU což je kombinace kernelu BSD a Mach.

Když už je o tom řeč, máte někdo představu o tom, proč vlastně Apple BSD jádro nad ten mikrokernel posadil (podobně jako MS)? Kvůli nějaké teoretické budoucí rozšiřitelnosti o jiné machovské subsystémy? Už toho někdy využili, nebo to alespoň plánovali? Pokud vím (a moc toho o tom teda nevím :), i věci, kde bych to tak nějak čekal (Grand Central Dispatch) běží až nad BSD kernelem...

A MS? Ten už mikrokernel nějak pořádně využil?

Ten seriál jsem četl, ale nepamatuju se, že by tam byla odpověď :)

>> Moc nerozumím otázce, ale BSD použili jednak aby zefektivnili některé úlohy a aby získali POSIX API.

Myslel jsem ji přesně naopak: proč nepoužili samotné BSD? Co získali tím, že ho posadili nad Mach?

(možná se ptám úplně blbě, v těchhle věcech se fakt moc nevyznám :)

Pár informací je k nalezení na naší wiki

• http://trac.helenos.org/wiki/FAQ
• http://trac.helenos.org/wiki/ReleaseNotes/0.4.3
• http://trac.helenos.org/roadmap

Je ale pravda, že spoustu věcí týkajících se zajímavých vlastností a plánů zatím zkrátka držíme ve svých hlavách, protože náš "core" tým je poměrně malý a nikdo na HelenOSu nepracuje opravdu full-time.

Žádnou podrobnou roadmap s výhledem na 10 let dopředu a končící položkou "world domination" teda nemáme. Asi je to škoda, ale den má zkrátka jen 24 hodin :)

Netrpi mikrokernel vykonove oproti monolitickemu jadru?

Ano, komunikační overhead IPC bude vždy v principu o něco větší než běžné volání funkce. Většina vývoje kolem mikrojader v 80. a 90. letech se právě točila kolem toho zoptimalizovat tento overhead co nejvíce.

Myslím si ovšem, že v dnešní době už ten fyzický overhead nehraje takovou roli. Koupit si o 10 % rychlejší procesor kvůli overheadu mikdrojádrové architektury je triviální a je to rozumná investice, protože za odměnu můžeme získat modulární, snadno udržovatelný a bezpečný kód. Údržba složitého monolitického softwaru, kde drobná chybka v málo podstatném modulu může způsobit pád celého systému, se jeví jako mnohem dražší a dlouhodobá investice.

musi dochazet mnohonasobne vicekrat ke "context switch"

Tohle je tak trochu nepochopení. V dobře navrženém mikrojádrovém systému dochází (za předpokladu asynchronní komunikace) ke zhruba stejnému počtu přepnutí kontextu jako v monolitickém systému — především z důvodu preempce nebo blokování.

Mikrojádrové systémy se zkrátka nesmí programovat tak, že se vezme "monolitický" sekvenční kód s funkčními voláními a ten se mechanicky převede na synchronní zasílání zpráv. Když se vhodně využije asynchronicita komunikace, koncepty jako future a promise a rozumný způsob předávání dat, tak se převážná část overheadu redukuje na nutné minimum.

jedna komponenta "zblazni" dokaze saturovat cely system jen rezii zprav

Počet zpráv, které může mít jedna komponenta v jeden okamžik "ve vzduchu", je omezen. Další zprávy si frontuje ve vlastní režii a tudíž ne více času, než je naplánována plánovačem. Takže jedna komponenta nikdy nezasaturuje celý systém.

Jistě se může stát, že nějaký proces bude soustavně "vyžírat" veškery procesorový čas, který mu plánovač dá, ale to se pochopitelně může stát i v monolitickém systému.

ji je treba napr. restartovat

Jak jsem už psal někde výše, restart podle mě nic neřeší :)

Jak se vlastne takovy system debuguje pri programovani, myslim tim kdyz se vse odehrava dost asynchrone?

Souhlasím, že debuggování asynchronní komunikace je složitější než debuggování sekvenčního kódu. Je potřeba sledovat komunikaci a všechny komunikující strany. V principu to dost připomíná ladění síťové komunikace ..

Na druhou stranu, v dohledné době budou mít procesory asi jen víc a víc jader a hardwarových vláken, takže luxusu přehledného sekvenčního kódu si stejně asi moc neužijeme :)

"Myslím si ovšem, že v dnešní době už ten fyzický overhead nehraje takovou roli. Koupit si o 10 % rychlejší procesor kvůli overheadu mikdrojádrové architektury je triviální a je to rozumná investice, protože za odměnu můžeme získat modulární, snadno udržovatelný a bezpečný kód. Údržba složitého monolitického softwaru, kde drobná chybka v málo podstatném modulu může způsobit pád celého systému, se jeví jako mnohem dražší a dlouhodobá investice."

Matematická poznámka: cena za upgrade hardware ale roste lineárně s počtem strojů, zatímco cena údržby software obecně nikoliv. Takže když jich máte opravdu hodně...

cena za upgrade hardware ale roste lineárně s počtem strojů

Cena za údržbu software zase roste s jeho velikostí. A dokonce bych se nebál tvrdit, že rychleji než lineárně.

Jestli vyjde ten trade-off v konkrétním případě lépe pro monolitický nebo modulární systém, to se skutečně nedá obecně a univerzálně rozhodnout. Netvrdím, že můj MP3 přehrávač musí řídit mikrojádrový operační systém složený z 25 komponent. Ale v případě jaderné elektrárny bych zase usínal hůře, kdybych věděl, že ji řídí program napsaný v jediném modulu :)

"Cena za údržbu software zase roste s jeho velikostí. A dokonce bych se nebál tvrdit, že rychleji než lineárně."

To je dost možné, ale software je jeden, zatímco strojů na kterých běží můžou být statisíce. Chtěl jsem tím podotknout, že ta skutečnost, že se to jádro lépe udržuje a vyvíjí, by se nakonec měla odrazit na nějaké produktivní vlastnosti - vyšší rychlost, vyšší spolehlivost, menší paměťová náročnost, spotřeba proudu nebo já nevím co ještě (tipoval bych, že spolehlivost bude horký kandidát). Pokud ne, tak na velkém počtu strojů vždycky "asymptoticky" prohraje.

> Jak se vlastne takovy system debuguje pri programovani
Debugovani takovych systemu ma sva specifika, na prvni pohled to mozna vypada zahadne, ale v praxi to muze byt i pohodlnejsi nez treba desktop monolyticka aplikace. Tady muzete mit porad spustene procesy, ktere komunikuji s tim debugovanym, muzete je behem toho ovladat, nejsou zamrzly a kdyz objevite v jedne komponente chybu, tak ji opravite a restartujete. Kdyz vam pak dobre funguje vyhledavani komponent a obnovovani spojeni, tak je z ladeni radost :-)

...radost si pocist.

Sice jsem některým věcem v dotazu úplně neporozuměl ("objektový derivát"), ale obecně se dá říci, že třeba interní API mikrojádra HelenOSu mají objektový charakter.

Odpověď na skoro všechny dotazy typu "proč jsme něco neudělali jinak" je bohužel taková, že den má jen 24 hodin. Některé věci jsou v současné době implementovány jen provizorně, spousta funkcionality chybí, spoustu věcí chceme předělat a možná ještě víc věcí bychom chtěli předělat, kdybychom měli energii zamyslet se nad nimi ještě lépe a důkladněji.

Ovšem HelenOS je open source projekt a pokud si myslíte, že můžete přispět dobrou myšlenkou nebo ještě lépe patchem, budete srdečně vítán!

http://trac.helenos.org/wiki/Screenshots
http://trac.helenos.org/attachment/wiki/FreeRunner/gta02_first_contact_d2x.jpg

Jen tak pro ilustraci .. :)