Názory k článku
Proč není Hurd ani po dvaceti letech hotový?

tak nejdriv rozhovor s Jakubem Jermarem o HelenOS, ted Hurd, priste nasazeni Hurdu... vracime se do 90. let z pohledu pana Tanenbauma? :)

Ne vazne, chtelo by to trochu odbornejsi clanek. Nevim, ale pokud nekdo o Hurdu slysel, tak asi vi, ze je to mikrojadro a co to vlastne znamena. A clanek moc neodpovida nadpisu - vlastne by se to dalo shrnout do nekolika slov: malo vyvojaru, malo nadseni, malo casu.

Kdyz uz, tak by bylo fajn poradne rozebrat koncepty Linuxu, Hurdu a HelenOS, v cem je ktery lepsi, proc by HelenOS nemel skoncit jako Hurd, detaily a tak. Ale jinak diky za ctivy clanek :)

V dobe, kdy jsme zacinali psat HelenOS, byla to pro me nejlepsi varianta povinneho predmetu SW projekt. V podstate mi bylo jedno, jestli to bude mikrojadro a jestli to ma nejakou budoucnost. Proste jsem si chtel udelat skolu na necem k cemu budu mit blizko a bude me bavit.

Dnes po letech vidim, ze:

1) mikrojadro je opravdu dobra myslenka - ladil jsem ted nekolik chyb v ovladacich v linuxu a kazda takova jednoradkova oprava trvala nekolik tydnu. Kdyz vam jadro pada a vy fakt nevite, kde v tom 2MB souboru je problem ... :D

2) Co tak obcas zaslechnu, HelenOS se docela rozjizdi jako zaklad pro prace lidi na MFF, kteri se chteji OSy zabyvat - je to minimalne zajimavy studijni projekt. A jakub je schopny clovek, ne jen jako programator, proto verim, ze se mu HeleOS muze podarit zmarketovat - a to je to hlavni - kod se da prepsat, ale kdyz neumite prodat, co mate .... :D :D :D

A já myslel, že to je teprve nějakých 14-15 let, co se o to snaží.

Myšlenka použít mikrojádro určitě není slepou uličkou, viz Mac OS.

Jenže to Linus nemůže připustit. Nebylo by to politicky vhodné hodnocení.

Myslíš ten Mac OS (X), který jede na XNU, hybridu monolitu a mikrokernelu, kombinaci Mach a BSD, právě proto, že stejně jako všichni ostatní prostě nedokázali postavit prakticky použitelný systém jen na Machu? :)

MacOS , neni zrovna moc mikrojadro , v MacOS X , uz je mikrojadro ale nad nim je bsd kernel + hafo dalsich vrstev zajistujicich kompaktibilitu s predchozimi OS ... takze elegance zmizela a slozitost dost neumerne narostla ....

Zajimave je napr jak se vyvinulo WinNT jadro ... --> hybridni kernel

A funkcni mikro jadro / ci spis nanojadro je napr QNX

mac so neni mikrojadro... to je len marketingovy zvast.

Taky asi před 2 léty jsem zkusil Debian s Hurdem. A můžu Vás uklidnit, počítač to nezničí a nevím, proč by to nemělo jít bez linuxu nainstalovat... Moje zkušenost je ale taková, že to bylo fakt hodně pomalé a tuším, že ani na tom nejely X. Prostě work in progress...

Na druhou stranu (prosím bez flamu) Hurdu docela fandím, protože Linusovo jádro mi pořád připadá jako dlouhodobě nasazené provizorium.

Před pár lety, když byl K14 horkou novinkou, tak jsem ho nějakou dobu zkoušel v qemu a použitelné to bylo, jen to vyžadovalo trošku experimentování a hodně čtení dokumentace/zdrojů, aby člověk zprovoznil alespoň myš v X.

Ale podle současné dokumentace to vypadá, že je to o velký kus snažší a dokonce jsou k dispozici i připravené qemu image a livecd :). Takže PC zvědavého tvora nemusí být vůbec ohroženo :).

Hardware, ktery muzete znicit pomoci software si nic jineho nezaslouzi :)

A co ArchHurd? Já jsem jednou natahoval - a nenatáhl, od té doby se mi tu válí CD... Nějak není čas experimentovat.

Zat9mco GNU Hurd se potácí odnikud nikam, tak firma NextStep a dnes Apple nad Machem vyvinuli jádro XNU a následně postavili Mac OS X. Zakopaný pes nebude v architektuře...

No ale po pravdě, právě mikrojádro na Mac OS X neoplývá bůh ví jakou rychlostí - ve srovnání s Linuxem nebo Windows. A proč se mikrojádro vyplatí a proč ho Apple zvolil? Přesouváme od jednoprocesorových počítačů k víceprocesorovým a vícejádrovým. Mikrojádro má mnohem lepší vyhlídky a nadějnější budoucnost při použití na víceprocesorových systémech. V monolytických jádrech bude s paralelním zpracováním dat vždy problém - to už je vidět nyní na jádře Linuxu.

> V monolytických jádrech bude s paralelním
> zpracováním dat vždy problém

Muzete to trosku obsahleji vysvetlit?

(monoliticky urcite neznamena, ze muze bezet v dany okamzik jen na jednoum CPU, stejne tak jako vice "serveru" s mikrojadrem neznamena, ze paralelni beh na mnoha CPU bude zadarmo)

Ja bych to chapal tak, ze moniliticke jadro klidne muze bezet paralelne na vice CPU(nejspis to bude i rychlejsi) kdyz to ale spadne tak se bude tezko dohledavat proc to spadlo. Mozna, ale ze to s mikrojadrem bude stejny, delat troubleshooting neceho co je zalozeny na zpravach je peklo, stacktrace je preci jenom citelnejsi.

>> V monolytických jádrech bude s paralelním
>> zpracováním dat vždy problém

>Muzete to trosku obsahleji vysvetlit?

Kdyz budu cynik, tak bude problem zpracovat je paralelne aniz by to zaroven bylo tak pomale jako na mikrojadru :-) . Ale ono to tak vlastne je - pokud je to na mikrojadru snazsi, tak proto, ze ty data jsou rozkopirovany, vtip je v tom to udelat bez kopii.

Mikrojádro ale právě často je bez kopií a bezpečné díky tomu, že paměť mezi procesy se sdílí a hlídá hardwarově pomocí stránkování, zatímco monolitické jádro musí vytvářet softwarové ochrany, které jsou stále pomalejší a pomalejší, protože vyžadují memory barriery, tedy serializaci, i v místech, kde by přístup k paměti mohl zkolidovat, ale v daný okamžik nezkoliduje.

Predpokladam ze pri monolitickom jadre sa niektore systemove sturktury zdielaju a kdeze vsetko bezi v jedom kernel space nieje problem aby ich omylom prepisal nejaky zly ovladac ktory neji dobre napisany ohladom smp a multithreadingu.To je dan za potencionalne vyssiu vykonnost monolitickeho jadra a riesi sa to zamkami a asi aj kadejakymi necistymi hackmi.Oproti tomu pri mikrojadre uz zo samotneho navrhu kazdy modul je samostatny a vlastne moze bezat ako thread na samostatnom jadre.
V podstate asi aj vdaka tomu mozu zacat byt mikrojadrove kernely atraktivnejsie.V casoch jednojadrovych procesorov nizsi vykon bol asi vyraznejsi (rezia kontext switchu atd.) ale dnes ked je jasny smer viacjadrovych procesorov to moze byt bez problemov.

On může mít mikrojádrový systém i vyšší výkon.

Lidský mozek nedokáže prostě udržet v hlavě všechny detaily nad určitou velikost. Takže jakmile to přesáhne určitý rozsah, tak se řada kódu i striuktur duplikuje. Vytvářejí se virtuální rozhraní a vnitřní volání kernelu. Obojí řeže výkon dolů.

Prostě unix byl postaven na pár desítkách tisíc zdrojových řádkách v kernelu a tam koncepty fungovaly báječně. Včetně konceptu výkonu a včetně konceptu spolehlivosti.

Mikrokernel není nic jiného, než tento koncept vrátit. Udělat opět maličký kernel.

Nad obrovským monolitem zvíci miliónů či desítek miliónů řádků prostě spolehlivost neuděláte a výkon také není takový jaký by mohl být, protože se prostě věci v jádře budou duplikovat (nikdo nemá přehled nad celým jádrem do detailů) a občas se budou věci propasírovávat vnitřními voláními jádra,které jsou tam také proto, aby lidský mozek byl schopen vývoj jádra vůbec ukočírovat.

Jinak pro tuto debatu je hlavní: Hurd a mikrojádrové os nejsou totožnou množinou, což tu řada diskutujících zcela zjevně nechápe.

Apple si ho zvolil už na konci devadesátých let, kdy ještě multiprocessory zdaleka nebyly na domácích počítačích, což je cílová skupina Apple. Je možné, že když to prostě naprogramovali, aniž by jim do toho někdo kecal, tak to (na omezené množině hardware) prostě funguje.

Ehm ale on si to zvolil Next který opravdu necílil na domácí zákazníky. Pak Apple stáhl nazpět Steve Jobse a dostal OS jako premii :-)

Pak Apple koupil OS a jako premii dostal nazpět Steve Jobse :-)

DayStar (výrobce klonů) měl 2 a 4 procesorový systém již v roce 1996 (běžel na něm Mac OS 7.5/7.6), Apple prodával dvouprocesorovou G4 (rok 2000 - Mac OS 9.0.4), k tomuto počítači nedodával Mac OS X, ten byl uveden až o rok později.

Pane Krčmáři, sám píšete, že mikrojádro má 10000- řádek kódu. Tak kde se bere to zpoždění? Navíc píšete, že používají existující mikrojádra (jen architekturu nebo i kód). Kolik na tom dělá vývojářů?

Na můj vkus příliš moc sádla a málo masa.

mikrojadro muze mit treba 10 tisic radek.
ale hurd jsou i ty serverove programy co bezi nad mikrojadrem,
a tam bude potreba zhruba stejne mnozstvi kodu jako v linuxovem jadre.

I tak by neměl být problém vydat seznam kompatibilního HW s jehož použítím to bude běhat bez problémů. Navíc mi neříkejte, že všechno musí být napsáno na zelené louce. Existuje někde takový HCL příp. popis stavu implementace jednotlivých částí Hurdu? Na jejich stránce jsem v rychlosti nic nenašel.

Ja som optimalizoval program, mam uz iba 1 riadok kodu a aj tak je to cele strasne pomale. A to som odstranil vsetko co by mohlo zdrzovat: cakanie na vstup, vystup, pristupy na disk a program je cely v cache procesoru. Tu je moj program:

while (1) ;

Nejde ani tak o pocet riadkov kodu, ale o to, ze to co spravi pri jednom volani monoliticky vsetko v kernel-space, mikrokernel musi neustale prepinat kontexty (ACL - extra proces, FS - extra proces, device driver - extra proces,...) a toto nie je trivialne spravit dobre.

To je trochu střelba mimo. Ptal jsem se na rychlost vývoje. Nikoli běhu.

vsak jo, rychlost vyvoje. nevyviji (jen) mikrojadro, ale hlavne ty servery pro hurd. a ty servery musi implementovat to co implementuje linuxove jadro. tj. i v hurdu je kodu zhruba jako v linuxu.

> V současnosti výměna mikrojádra nepokračuje a většina vývojářů se věnuje práci
na stávajícím mikrojádře GNU Hurd.

Tady by bylo myslím názornější napsat GNU Mach.

existuje rovnez projekt linuxoveho jadra beziciho na mikrojadrem L4.
autori planuji rozsekat linux na mensi kousky, ktere by bezely jako
samostatne servery, zatim je linuxove jadro jako jeden server na L4.

toto je velmi zajimave, mate nejakou zkusenost ?

Mě v článku chybí kritické srovnání koncepce microjádra a monolitu. Představa, že microjádro je jednoznačně technicky nadřazeno monolitu, je najivní.

1. Microjádro má obecně nižší výkon a větší latenci. Nové náklady vytváří přepínáním kontextů mezi mikrojádrem a dodatečnou vrstvou serverů. Navíc roste režie na úkoly vyžadující komunikaci mezi mikrojádrem a servery.
2. Linux obsahuje technologie, které přinášejí některé výhody tradičně spojované s mikrojádry. Například Linux umí na požádání nahrávat, vykonávat a uvolňovat kód v jádře (jaderné moduly), rozhraní FUSE umožňuje vytvořit ovladač běžící mimo jaderný prostor...
3. Větší spolehlivost microjádra je mýtus. Důsledky pádu kritického serveru (např. poskytujícího virtuální souborový systém) jsou v praxi de facto stejné jako důsledky pádu celého jádra. Nejde provést izolovaný "seamless" restart tohoto serveru, aniž by spadly kritické procesy operačního systému.
4. Existují efektivní univerzální způsoby, jak vykonat kód a přitom zabránit kódu v čítení/zapisování mimo svojí alokovanou paměť. (Jde o některé experimentální patche kompilátoru GCC, virtualizace a chráněný přístup do paměti...) K oddělení paměťových prostorů různých subsystémů jádra není potřeba měnit architekturu jádra.
5. Co když potřebuji do jádra novou funkcionalitu? V Linuxu stačí zavést jeden jaderný modul. V microjádře může být problém daleko těžší, protože může být třeba současně a synchronizovaně pozměnit několik serverů a microjádro. Například vytvořit patch ksplice pro systém s microjádrem by bylo extrémně obtížné.

Ad 3) No třeba když spadne ovladač grafiky, tak ho ale stačí restartnout a jede se dál. To mi ostatně dělá Windows 7 bežně, když NVidia driver jednou za čas spadne - akorát na tři vteřinky zčerná obrazovka a jede se dál.

A Windows je zaroven monolit

To samozřejmě není. Architektura Windows je naopak popisovaná jako modifikovaný mikrokernel.

Jako modifikovaný mikrokernel to popisuje Microsoft, protože to hezky zní, ale ve skutečnosti je to hybridní jádro, což je ale vlastně monolitické jádro programované jako mikrojádro. Linuxový systém modulů, FUSE a CUSE je tomu hodně podobný (i když u Windows se ty user-space servery využívají víc).

MS naopak vidí NT jako mikrojádro s některými servery z důvodu výkonu běžícími v kernel mode.

To je váš první smysluplný příspěvěk tadu na rootu.Gratuluji.

windows je hybrid.

Mě v článku chybí kritické srovnání koncepce microjádra a monolitu. Představa, že microjádro je jednoznačně technicky nadřazeno monolitu, je najivní.

Tak co se týká kocenptu, tak je mikrojádro obecně jistě technicky nadřazeno monolitu. O tom není pochyb. To, s čím se mikrojádra potýkají jsou implementační problémy.

ad 1. To mi přijde stejné jako hodnocení, že 1:1 kernel má obecně nižší výkon a větší latenci než N:1 příp. diskuse 1:1 vs. N:M nebo režie virtualizace atd. atd.

ad 2. To ano, ale chybí ta izolace.

ad 3. Pád VFS není zrovna běžný pokud ho nesejme ovladač, což běžné je. A to právě izolace řeší. O mýtus se nejedná.

ad 4. O tomhle nevím, ale působí to na mne jako "chtěli bychom stejné vlastnosti jako mikrojádro, ale nechceme (veřejně) připustit, že to mikrojádro řeší lépe". Také to může být cesta, jak z Linuxu to mikrojádro udělat, protože změna architektury linuxu formou revoluce je neprosaditelná.

ad 5. Mě to tedy přijde u mikrojádra daleko jednodušší právě díky izolaci a definovaných rozhraních. Nehledě k tomu, že si v případě mikrojádra dokážu představit vcelku jednoduše fault-tolerant rozšíření na úrovni subsystémů.

ad 1. Přepínání kontextu je extrémně drahá operace. Mikrojádra mají obecně podstatně nižší výkon (řádově procenta) než monolitická jádra. Nízký výkon je i hlavní problém u HURDu.

ad 3. Neřeší to problém, stále je špatný ovladač. Mimochodem Linux umí izolovat problémové ovladače souborového systému přes rozhraní FUSE. Proč by se měla vůbec vyplatit izolace ovladače virtuálního souborového systému do samostaného serveru?

ad 4. Například Microsoft myšlenku řízeného jaderného kódu celkem úspěšně rozvíjel v experimentálním projektu Singularity. Podle mého názoru monolitické jádro s řízeným kódem řeší vcelku nepodstatný problém izolace subsystémů lepším způsobem než mikrojádro.

ad 5. I monolitické jádro může mít jasně definovaná izolovaná API/ABI rozhraní.

ad 1. Právě ono přepínání kontextu je implementační problém (ve většině případu vázaný na i386) a nikoli koncepční. Koncepce mikrojádra nepředepisuje jakým způsobem je provedena izolace. Řádově o procenta nižší výkon je až na výjimky nezajímavý. Virtualizace vám sebere to samé (ne-li víc) a nikoho to nepálí. Výkon HURDu bych u projektu, který je de facto stále na začátku, neřešil.

ad 3. Řeší. Restartuje se ovladač a jede se dál. Chyby, především ty ve spojení s HW, budou existovat vždy. Jde o to, jak se v praxi řeší situace, kdy nastane výjimka. A co se týká vyplatit vs. nevyplatit tak je to stejné jako jestli se vyplatí programovat objektově nebo neobjektově.

ad 4. Tak zrovna Singularity je také typ mikrojádra. Jen s tím rozdílem, že režii kontextového přepínání i386 řeší jinak. Nicméně se subsystémy tváří také jako procesy.

ad 5. Jistě, ale tato existence v monolitu nijak neovlivňuje možnosti změn v mikrojádře.

ad 4. A je dobré říci, že SIP (Software Isolated Processes) v Singularity mají proti "klasickým" procesům naprosto zanedbatelnou režii.

„ad 1. Přepínání kontextu je extrémně drahá operace. Mikrojádra mají obecně podstatně nižší výkon (řádově procenta) než monolitická jádra. Nízký výkon je i hlavní problém u HURDu.“

Přepínání kontextu může být i extrémně levná operace. Záleží na implementaci a okolnostech.

A znovu, Hurd není jediný mikrokernelový operační systém.

„ad 3. Neřeší to problém, stále je špatný ovladač. Mimochodem Linux umí izolovat problémové ovladače souborového systému přes rozhraní FUSE. Proč by se měla vůbec vyplatit izolace ovladače virtuálního souborového systému do samostaného serveru?“

Protože nebude kerneleovým kódem a jako taková nezhroutí při problémech systém. Ten bude stabilní jako skála.

Další, ještě významnější pak je, že pro user space se programuje luxusněji, rychleji a efektivněji, než cokoli co je v jádře, nebo aspoň háčky v jádře.

Třetí důvod – souborový systém může být distribuovaný přes celou počítačovou síť.

Čtvrtý důvod – možnost restartu driveru i vfs při problémech. Tak jak to dělá Linux v kernelu to ani vzdáleně nedělá izolaci a spolehlivost jaká je v mikrokernelu.

Tvůrce Unixu napsal před časem knížku. Jeden z věcí, co by dnes na unixu změnil je jeho příliš silou závislost na filesystému a přesném rozložení adresářů.

„ad 4. Například Microsoft myšlenku řízeného jaderného kódu celkem úspěšně rozvíjel v experimentálním projektu Singularity. Podle mého názoru monolitické jádro s řízeným kódem řeší vcelku nepodstatný problém izolace subsystémů lepším způsobem než mikrojádro.“

Neřeší. Možnosti chyb v Singularity jsou daleko rozsáhlejší. Kód, který musí být stabilní aby systém byl stabilní v Singularity je mnohem větší, než u mikrokernelů.

Například musí běžet bezchybně celá virtuální mašina .NETovského kódu a její překlad do strojáku.

Pomíjím to, že Singularity není operační systém, ale virtuální stroj. To už můžete za oprační systém prohlásit třeba JVM, bude to totéž.

ad 4. Singularity nevyžaduje .NET runtime, ani toho času kompletní .NET runtime neposkytuje aplikacím.

Singularity je operační systém. Píše se pro něj v C#, resp. čemkoliv co překládá do CIL (".NET" jazyky). U klasického OS byste mohl tvrdit, že to není OS, ale runtime jazyka C :)

Podle mě je budoucností právě Singularity. Vyjma architektury mikrokernelu nabízí navíc možnost formální verifikace prakticky celého kódu, což projekt napsaný v C nikdy nemůže nabídnout. To by mělo vyřešit celou škálu problémů se spolehlivostí a bezpečností SW. Výkon vypadá ve srovnání s klasickými systémy dobře. Některé věci jsou výrazně rychlejší (IPC), jiné trochu pomalejší; výsledek je srovnatelný.

"Pomíjím to, že Singularity není operační systém, ale virtuální stroj." - tak to ani omylem. Ono je to sice napsané v C#, ale přeložené je to do strojového kódu, žádné MSIL se nekoná, tudíž ani žádné virtuální stroje neběží.

„Mě v článku chybí kritické srovnání koncepce microjádra a monolitu. Představa, že microjádro je jednoznačně technicky nadřazeno monolitu, je najivní.“

Já to vezmu ironicky. Představa, že deset miliónů řádek kódu v monolitickém jádře bude absolutně bezchybná, protože jakákoli chyba v monolitickém jádře znamená, že už nelze zaručit spolehlivost a stabilitu – je naivní.

Právě proto se mikrojádra dělají. Koncept unixu stál v době, kdy unix kernel měl pár tisíc řádek zdrojáku.

Momolit v tak rozsáhlé podobě jako Linux existuje jen proto, že se na jeho vývoji podílí enormní množství vývojářů. Ono se to časem projeví při dalším růstu Linuxu.

„1. Microjádro má obecně nižší výkon a větší latenci. Nové náklady vytváří přepínáním kontextů mezi mikrojádrem a dodatečnou vrstvou serverů. Navíc roste režie na úkoly vyžadující komunikaci mezi mikrojádrem a servery.“

Stejně tak obecně programovací jazyk C má menší výkon, než ručně optimalizovaný stroják. Skript v bashi má obecně nižší výkon, než přepsat totéž do čistého jazyka C. Perl skript má rovněž mnohem nižší výkon, atd.

Koncept XWindows má nižší grafický výkon, než přímé volání grafiky třeba ve Windows, nebo QNX.

Stejně tak koncepty operačních systémů sálových počítačů, kde se volaly přímo rutiny na zápis na diskový sektor určitě měly větší výkon, než zápis přes filesystém Linuxu.

Prostě píšete hovadiny. U mikrojádra je nutný dobrý návrh mikrojádra a komunikace. Pokud se navrhne špatně, výkon je mizerný. Pokud se napíše dobře, výkon je dobrý.

Je to stejné jako s tím, že když budete zapisovat na disk přímo sektory, Váš výkon bude větší, než „rozežrané“ služby kernelu Linuxu pro práci se soubory.

To je totéž.

„2. Linux obsahuje technologie, které přinášejí některé výhody tradičně spojované s mikrojádry. Například Linux umí na požádání nahrávat, vykonávat a uvolňovat kód v jádře (jaderné moduly), rozhraní FUSE umožňuje vytvořit ovladač běžící mimo jaderný prostor...“

Demogogický argument. Základní výhodu mikrojádra, totiž spolehlivost a necitlivost na chyby v driverech bez dopadu na stabilitu systému.

Dále možnost nativně mít distribuovaný systém na více počítačích tvářících se jako jeden počítač s jedním operačním systémem.

Možnost vývoje driverů stejně luxusně jako běžného user programu.

A desítky dalších.

Tento argument neobstojí, protože Linux kernel je ten poslední, který by dával výhody mikrojádra. Je to poslední rozšířenější operační systém, který je tvrdý monolit. Ani Windows, ani Mac OS, stejně jako řada dalších operačních systémů už nejsou čistým monolitem.

„3. Větší spolehlivost microjádra je mýtus. Důsledky pádu kritického serveru (např. poskytujícího virtuální souborový systém) jsou v praxi de facto stejné jako důsledky pádu celého jádra. Nejde provést izolovaný "seamless" restart tohoto serveru, aniž by spadly kritické procesy operačního systému.“

Pište do Blesku. Víc k tomuto nemám co dodat.

Samozřejmě že to lze, zejména tehdy, pokud je mikrojádro použito k tomu, že všechna zařízení včetně filesystému a včetně fyzických počítačů jsou několikrát.

Mikrojádro dokáže fungovat nad více počítači, více systémy.

„4. Existují efektivní univerzální způsoby, jak vykonat kód a přitom zabránit kódu v čítení/zapisování mimo svojí alokovanou paměť. (Jde o některé experimentální patche kompilátoru GCC, virtualizace a chráněný přístup do paměti...) K oddělení paměťových prostorů různých subsystémů jádra není potřeba měnit architekturu jádra.“

Mikrojádro pěkně prosím neodděluje pouze paměťové prostory.

Co když neselže paměť, ale něco jiného?

Spolehlivost mikrojádra je prostě dána jeho architekturou.

„5. Co když potřebuji do jádra novou funkcionalitu? V Linuxu stačí zavést jeden jaderný modul. V microjádře může být problém daleko těžší, protože může být třeba současně a synchronizovaně pozměnit několik serverů a microjádro. Například vytvořit patch ksplice pro systém s microjádrem by bylo extrémně obtížné.“

Když potřebujete novou funcionalitu, tak jí naprogramujete asi tak 100× snadněji, než v monolitu, protože programovat pro kernel je méně efektivní, než pro user space.

Jsou věci, které jsou pro mikrojádro obtížnější a naopak.

Nicméně zažil jsem hodně demagogických argumentů proti mikrojádru, ale málokterý byl tak demagogický jako těchto 5 bodů.

To je argument jak stehno, fakt.

Existuje X úspěšných mikrokernelových systémů dotažených do konce. Velmi úspěšných.

Viděl jsem souseda hrát na klavír a šlo mu to blbě. Závěr Michala Káry => hraní na klavír nikdy nemůže znít pěkně.

Skvělý pokus jak jeden neúspěšný příklad zobecnit na všechno. Jen tak dál!

Řekl bych, že do první použitelné verze Linuxu bylo investováno méně, než do celého (pořád ne použitelného) Hurdu doteď.

Milan Ponkrác: To neměl být argument, spíš takové rýpnutí, které jsem si nemohl odpustit. Pokud jste ho pochopil špatně, tak se omlouvám :-) Ale ten rozdíl mezi teorií, podle které jsou mikrokernely o mnoho světelných let vepředu, oproti praxi, kde ten rozdíl zdaleka takový není, je IMHO do očí bijící.

Hurd je použitelný a je tak na úrovni toho prvního Linuxu.

Já jsem ten argument pochopil velmi dobře a správně.

Protože rýpnutí do toho, že soused špatně hraje na klavír, a proto je koncepce klavíru špatná – je docela zajímavou psychologickou sondou do Vašeho způsobu myšlení. A díky tomu jsem pochopil, že řada lidí ztotožňuje Hurd a jeho vlastnosti s vlastnostmi mikrojádra.

Zvláštní je, že nikdo nezmiňuje, že třeba mikrojádrový operační systém minix, který používal i sám Linus a o kterém se vyjádřil, že bez jeho inspirace by Linux nikdy nevznikl – to se nehodí nikomu do krámu, co?

Hurd je prostě jeden z velmi mála neúspěšných mikrojádrových operačních systémů kolem kterých je mnoho úspěšných mikrojádrových systémů.

Všechno co si přečtete o mikrojádře na masových zdrojích jako je wikipedie je prostě lež. Linuxových nadšenců je příliš mnoho, mají čas a jsou příliš aktivní na to, aby pustili pravdu o mikrojádře ven a dovolili přezentovat jeho úspěšné a vynikající vlastnosti.

Kdo chce najít pravdu o mikrojádře, musí si uvědomit, že je poněkud pokroucená linuxovým ideocentrem pravdy. A musíte hledat jinde, číst si nezaujaté věci a přemýšlet. Na české wikipedii třeba jsou o mikrojádře dokonalé sci-fi bajky a pověsti (napsat kdo za to může je zakázané slovo – takže Ker, pak následuje šlág a končí er, když to napíšete přímo, root to nepustí).

Mikrojádro je velmi úspěšný koncept. Pokud zvládnete dobře navrhnout mikrojádro (pár desítek tisíc řádků kódů), což chce trochu více zkušeností, než monolit, pak už se na tom v zásadě nedá nic zkazit. Nad návrhem mikrojádra je třeba přemýšlet a hodně. Ale pak už jsou obrovské výhody.

Podívejte se na QNX, či na řadu dalších systémů. Kromě Linuxu budete jen stěží nacházet operační systém, který by si z koncepce mikrojádra něco nelíznul.

To jste napsal dobre:
"Mikrojádro je velmi úspěšný __koncept__"

Ale Linux je uspesny produkcni system. Treba Google na tom dela business za miliardy dolaru, ne?

Podle vaší reakce soudím, že jste to pochopil špatně. Když už se budeme držet toho klavíru, tak by to bylo asi takhle: Miloslav Ponkrác tvrdí, že kytara je příšerný, nešikovný hudební nástroj, zatímco klavír je super hudební nástroj a že se na něj dají zahrát 100x lepší písničky než na kytaru.

A já přitom mám souseda, co má docela hudební talent a hraje na klavír. Hraje na něj relativně slušně. Není to špatné, ale není to tak nijak výrazně lepší než moje hra na kytaru. Takže si logicky odvodím, že s tím páně Ponkrácovým tvrzením to v praxi nebude až tak horké :-)

Jinak, moje argumentace není založená jen o HURDu. Ano jsou jiné mikrojádrové systémy, lepší (vaše argumentace, že HURD je neúspěšný proto, že se snaží převést UNIX/Posix koncepty na mikrojádro zní rozumně). Prostě důkaz sporem - pokud by opravdu mikrojádrová architektura byla _v praxi_ o tolik výhodnější, jak tvrdíte, tak by mikrojádrové systémy musely monolity totálně převálcovat. Což se ale neděje - v praxi se používají monolity, mikrojádra i kombinace obou přístupů.

>> Všechno co si přečtete o mikrojádře na masových zdrojích jako je wikipedie je prostě lež.

Není to trochu přehnané? Např.:

However, Jochen Liedtke showed that Mach's performance problems were the result of poor design and implementation, and specifically Mach's excessive cache footprint.[10] Liedtke demonstrated with his own L4 microkernel that through careful design and implementation, and especially by following the minimality principle, IPC costs could be reduced by more than an order of magnitude compared to Mach. [...] Furthermore, performance does not seem to be the overriding concern for those commercial systems, which instead emphasize reliably quick interrupt handling response times (QNX) and simplicity for the sake of robustness.

http://en.wikipedia.org/wiki/Microkernel#Performance

Tak zrovna rychlost vývoje bych spíš přičetl "otevřené atmosféře" okolo vývoje kernelu v 90. letech než technickým aspektům. Linus se snažil řídit vývoj tak, aby kód v kernelu byl "dost dobrý", ale hlavně aktuálně dostupný, namísto čekání na teoretický "ideální" kód, resp. "ideální" rozhraní. Pro Linux bylo vždycky prioritou mít aspoň nějaký kód a být schopen ho vyměnit/upravit, až někoho začne fakt hodně štvát.

A dalším faktorem může být, že HURD jako GNU projekt určitě vyžaduje vzdání se práv ve prospěch FSF (v ČR naštěstí nemožné), zatímco přispěvatel Linuxu si zachovává veškerá práva ke svému kódu.

Tedy člověče, kritizujete někoho za demagogii, ale přitom si nevidíte na špičku nosu. Jste asi zarytým příznivcem mikrokernelu.
Miliony řádků kódu mikrojádrem neodpářete, žádá si je trend zesložiťování počítačů. Když někde něco klekne v user space, tak to stejně vynutí restart všeho závislého a akorát se ušetří čas POSTu.
Ad stroják>C>bash... To už trolujete?!? Autor kódu si zvolí kompromis mezi efektivitou vývoje a efektivitou běhu. To si myslíte, že to někdo neví?
U x86 je přepínání procesů pomalé. Nazýváte to jen pomalou implementací, která se doladí? Poradíte jako Cimrman Intelu, aby přikreslil tranzistor semhle a támhle a Otellini Vám zlíbá nohy?
Linux přináší některé výhody. Nerozumíte slovu některé? Navíc neshoditelnost je pseudovýhoda, protože, jak jsem psal výše, restartem serveru se závislé věci stanou nekonzistentní a efekt je stejný, jako restart normálního stroje.
Kde jste přišel na to, že Widle nejsou čistý monolit? Jejich zdrojový kód jsme neviděli, ale podle zkompilované velikosti a známých funkcí v nich obsažených mají Widle zhruba stejně kódu v jádře jako Linux a navíc tam natvrdo implementují své FS, což je u Linuxu volitelná věc a neomezuje ho. Naproti tomu Widle z jiného FS nenabootujete.
Co když neselže paměť, ale něco jiného? - To je dvojsečný argument. Navíc, pokud jádro zjistí, že je nestabilní HW, mělo by okamžitě zastavit systém. Pokusy o restarty služeb jsou jistá smrt pro spolehlivá data!
...protože programovat pro kernel je méně efektivní, než pro user space. - Tady je asi jádro pudla Vašich omylů. Ale nebudu dělat blbého. Jistě myslíte vývojově. Ale to si nemyslím. S relokací rozdíl v práci s pamětí ani nepoznáte. Výkon zase poznají všichni ostatní.
No, můžete si gratulovat, jak jste mi utroloval čtvrt hodiny života.

Windows opravdu běží spoustu kódu v kernel mode. Akorát je to na rozdíl od Linuxu modifikovaný mikrokernel. Tzn. modularita na úrovni kernelu, definovené interfaces. FS samozřejmě nejsou natvrdo implementované v jádře; vizte ntfs.sys, fastfat.sys, cdfs.sys. Bootovat lze jen z NTFS (v minulosti i z FAT), ale to je trivialita.

<cite>Windows opravdu běží spoustu kódu v kernel mode. Akorát je to na rozdíl od Linuxu modifikovaný mikrokernel.</cite>

to je hezky marketingovy nesmysl. mikrokernel od monolitu odlisuje prave to, kolik kodu bezi v privilegovanem rezimu. a ve windows v jadre bezi i takove zverstva jako GDI, registry, etc.

> U mikrojádra je nutný dobrý návrh mikrojádra
> a komunikace. Pokud se navrhne špatně, výkon
> je mizerný. Pokud se napíše dobře, výkon je
> dobrý.

Tohle tesat do kamene. Dobrý návrh rozhraní je důležitý u všech programových systémů (knihovny, síťové protokoly, ...).

Já bych si ale dovolil dodat, že dobrý návrh rozhraní je _fakt_ těžký, až bych řekl nemožný. Často nevíte, jak se změní svět za pár let a jak "kreativní" budou uživatelé vašeho rozhraní.

A tady je právě důvod neúspěchu HURDu. Podle mě dobrý programový systém musí spíš být připravený na to, že rozhraní stejně nenavrhne dobře, a být připravený snadno to rozhraní vyměnit, než investovat úsilí do návrhu "ideálního" rozhraní. Je asi jasné, že změnu rozhraní v monolitickém Linuxu uděláte velmi snadno, zatímco v mikrokernelu ne.

Mikrokernel z principu buduje rozhraní tam, kde mnohdy žádná rozhraní ani nejsou potřeba. Je to v jiném adresním prostoru, pak na přístup holt potřebujeme rozhraní.

Já bych si dovolil přidat ještě další aspekt, který dosud v diskusi nezazněl (aspoň jsem si nevšiml):

6. Vzájemnou izolaci umožňuje dnešní hardware jen na úrovni procesů uvnitř CPU. Ale počítač je přece daleko víc než jen CPU.

Co uděláte v případě, že ten údajně neprivilegovaný ovladač řekne třeba síťové kartě, aby další packet nakopírovala na adresu, na které se zrovna náhodou nachází kód mikrojádra? A neříkejte IOMMU, protože v současných počítačích nemáte za IOMMU všechna zařízení. Nebo že bych do té síťové karty poslal nový firmware, který bude tak často přenášet data po sběrnici, že celý počítač bude nepoužitelný.

Aby se tomuto zabránilo, muselo by být verifikovatelné nejen jádro, ale i ovladače a firmwary. A tím se dostáváme na úroveň složitosti monolitického systému, nebo vlastně "díky" asynchronnosti mikrokernelových serverů ještě k daleko vyšší složitosti.

Neříkám že mikrojádra nemají žádné použití, ale pro "obecný" operační systém běžící na všem od mobilu přes desktopy po mainframe a superpočítače IMHO není jiná alternativa než víceméně monolitický kernel.

Na vine je akademicke prostredi. Kdyz chci neco vymyslet- akademicke prostredi je pro to perfektni. Na zakladni vyzkum idealni.

Kdyz ale chci neco opravdu vytvorit- pak je jedno z nejhorsich moznych. Vetsi koncentraci v praxi nepouzitelnych snilku naprosto odtrzenych od reality s hlavou v oblacich a nulovym tahem na branku svet nevidel. Navic maji vetsinou zapornou motivaci- kdyz praci dokonci tak by se museli venovat necemu jinemu. Publikovatelne vysledky generuje i neustale motani se v miste, tak nad nima nikdo s bicem nestoji...

A ono je nekde dano, ze Hurd smi programovat jen zamestnani na univerzite a Linux jen lide pracujici v komercni sfere?

Neni.

Proste je to tak, ze Linux "funguje" a "fungoval", takze na sebe nabalil mnozstvi vyvojaru a dal uz to byl jen efekt snehove koule.

Zatimco Hurd se do te nabalovaci faze nikdy nedostal.

Nejde o to, ze ho vyviji akademici, jde o to, ze ho vyviji malo lidi.

Problém Hurdu je jednoduchý.

Všechny mikrokernely a vynikající a úspěšné mikrokernely, které znám začaly tímto: fuck off POSIX!!!

Problém je, že mikrokernel se musí naprogramovat a nabídnout jiné základní služby, než si představují akademici a musí se vybodnout na mnoho unix-like standardů jako je POSIX a řada dalších.

POSIX může být emulován až někde ve vyšších vrstvách.

Když si vzpomínám, jak jsou koncipované archiktektury úspěšných mikrokernelů, a zejména v průmyslu je jich mnoho, protože jiná architektura nedokáže zajistit potřebné vlastnosti jako je spolehlivost či další – všechny mají základníslužby nePOSIXové a neUNIXOvé.

Dokáží emulovat posix i unix služby. Ale je to pouze emulace ve vyšší vrstvě.

Akademici bohužel mají díky svým sklonům k čistotě velkou úctu ke standardům a mnoho z nich je svázáno s boomem unixu a vše navazujících standardů.

Ale doporučuji se podívat třeba na QNX.

Hurd to prohrál, protože v jádru se příliš soustředí na unix a jeho standardy. Jádro měl udělat úplně po svém a jinak. Zapomenout na unix, na posix i další – a pochopit, že unix like věci budou jen emulace. Bohužel mám pocit, že Hurdu trvalo 20 let, než přetavili mozek do tohoto poznání – a teď mohou začít.

Přesně. QNX by zasloužil mnohem širší uplatnění než při řízení průmyslových procesů a tabletu od RIM...

Přesně tak.

Hurd se snažil o totéž co feministky. Feministky se snaží být muži a lepší,než muži – a nějak se to nedaří.

Hurd jako mikrokernel se snažil být makrokernelem, respektive poměřovat se s makrokernelem a jít jeho cestami.

Každý mikrokernelový operační systém to prohraje, když se bude snažit dělat koncepty a služby makrokernelového systému. A to se stalo Hurdu.

Cokoli ostatního je zástupný problém. Hurd pouze zjistil, a pravděpodobně ještě bude zjišťovat, že s koncepty makrokernelu nevnikne žádný dobrý mikrokernel, a ještě to bude trvat tak 200 let.

Mikrokernel musí být od počátku i myšlenkami mikrokernel. Snažit se mikrokernel uplácat podle principů přesně protikladného uspořádání, tedy monolitu a nejprotikladnějšího monolitu – unixu prostě úspěšný mikrokernel nevyvolá.

Neexistuje tvrdší monolit, než unix. Nelze proto unixové principy uplatňovat na přesně opačnou architekturu – mikrokernel. Tedy v low level částech.

To je celý problém Hurdu. Nic jiného.

mmmm

Neni nahodou POSIX standard libc knihovny? Tudiz to s jadrem nema prilis spolecneho?
Nechci vam nic vyvracet, jen bych mela rad jasno.
Diky za vysvetleni ;)

Ano i ne. POSIX obsahuje kromě jiného i C knihovnu, ale také jsou tam věci jako soubory, pipe, signály, thready atd., které opravdu MAJÍ s jádrem hodně společného.

Myslel jsem, ze to je v podstate API pro user-space, kazdy den se clovek neco nauci :)
Dekuji za osvetleni.

> Hurd to prohrál, protože v jádru se příliš
> soustředí na unix a jeho standardy.

Tuhle implikaci příliš nechápu. Pokud chci mít z hlediska POSIXových aplikací verifikovaný a spolehlivý systém, je mi v zásadě jedno na které úrovni bude ten POSIX implementovaný. Verifikovat musím vše od POSIXového rozhraní nahoru.

Pokud chce být HURD jádrem pro GNU systém (který má celý user-land psaný pro POSIX), asi mu nic jiného než soustředit se na dobrou podporu POSIXu nezbývá.

Když bych se posunul o úroveň abstrakce výš - co je teda konkrétně na POSIXovém rozhraní tak špatného, že to brání efektivnímu použití mikrokernelové architektury?

> Nejde o to, ze ho vyviji akademici, jde o to, ze ho vyviji malo lidi.

A ja myslim ze presne o to jde, ze akademici jsou ta pricina. Linusuv cil byl (mozna ne uplne presne, ale v principu) rozbehat to na svym kompu, udelat nejaky fs a spustit pod tim gcc. Kdo chce vic at si to dopise a posle patch. Je jasne, ze na tohle chytnete daleko vic lidi, nez kdyz vasi prioritou bude mikrojadro, design a cistota. Proste kdyby to opravdu chteli rozbehat, tak resi uplne jine veci nez prechod na jine mikrojadro kazdych pet let. Sice by se dopustili kompromisu, ale bylo by to venku.

Ostatne vidim to i u sebe na svych soukromych hracickovych projektech. 20% casu travim implementaci noveho a 80% upravama a cistkama tak aby se mi to libilo. V praxi je ten pomer 70:30 a vysledky jsou samozrejme nekde jinde.

??

To jsem nekde rekl?

Ma teorie je, ze kdyz nekdo da na prvni misto cistotu a kvalitu navrhu, tak nesezene tolik lidi na vyvoj (treba proto, ze ostatni maji jiny nazor na to, co znamena kvalita, nebo nakolik se dopoustet kompromisu) jako nekdo, kdo si da za cil produkcni nasazeni (cti nejak to rozbehat :-) ). Dalsi tvrzeni je, ze tyto priority stanovili "akademici".

Jak to souvisi s TeXem netusim (pokud vim, tak ho Knuth stvoril aby v nem napsal knihu) a uz vubec jsem si nevsiml, ze bych zminoval, ze by se neco melo hazet do kytek.

Udělat čistý návrh napoprvé je holý nesmysl, případně dotek všehomíra. I v rukopisech největších skladatelů najdete škrtance, i největší malíři si předkreslovali a v průběhu realisace museli předělávat. Vývojář, který dělá něco nového, nejen nějakou rutinní záležitost, nutně musí postupovat ve dvou krocích:
1) Vytvořit si (teoreticky čistou) představu, jak by to mělo fungovat a podle ní zmastit velmi ušmudlanou, leč funkční implementaci.
2) Na základě získaných zkušeností s implementací přistoupit k přehodnocení těch nejzásadnějších konfliktů s teoretickými představami a celé to udělat znova, z jedné vody načisto; smířit se s tím, že dokonalá čistota není.

Říká se tomu prototypování. Po ujasnění, úpravě konceptu a jeho zapracování má následovat refaktorizace (dělat všechno znovu není nutnost). Nepředpokládám, že by se takhle dnes dělalo moc software.

Jednu vec nechapu

... mikro jadro je male (clanek rika 10000 radek), nic moc neumi a nedela ...

ale pro projekt je tak neprokonatelnym kusem kodu, ze nez napsat a udrzovat vlastni tak je lepsi dvacetl let znova a znova hledat tech par radek mimo vlastni projekt? Divne.

Rekl bych, ze problem je v ovladacich, kterych je malo (a proto ten system nic neumi), ktere ale z definice mikrojadra nejsou soucasti samotneho jadra (a proto je male).

To bych neřekl. Mluvíme tady o 20 letech vývoje. A určitě ne vše je potřeba psát z nuly. Spíš to opravdu vypadá na neefektivitu akademického prostředí jak o tom psal Michal2.

Soulasim...
Linux je uspesny hlavne proto, ze Torvalds je pragmatik a ne fanatik.
Pokud by neexistoval, Stallman a spol. by doted recnili a experimentovali bez pouzitelneho vystupu...

... a všichni bychom mezi tím používali BSD, které v době vzniku Linuxu zápasilo o svůj život u soudu kvůli licenčním tahanicím. :-)

Rekl bych, ze jen maly pohled na realitu vasi teorii zcela vyvraci - Stallman napsal pomerne velkou cast GNU projektu (zejmena GCC a Emacs, pokud vim). Takze rozhodne nebyl jen teoretik. (Navic i kolem Linuxu je dost lidi, ktere by bylo mozne oznacit za fanatiky (sic!) - Alan Cox, GKH..)

"Emacs, pokud vim"

Nad tímto jsem se trošku zarazil. Diakritika se občas hodí :-P

Taky jsem premyslel proc by napsal jeden (nepouzitelnej) editor a pak hned napsal jeden z nejlepsich.. (Kazdy at si prebere po svem, ktery je ktery) ;))

Nechapu, s cim polemizujete. Ja v tom rozpor, v cem ho vidi Karel Zak, nevidim.
Realita je jaka je.

K tomu ze neni treba vse psat z nuly. Nedovedu si predstavit, ze by Hurd mohl jen tak vzit ovladac z jadra Linuxu a zaintegrovat ho. Nejspis hlavne aniz by se pritom otestovalo konkretni zarizeni. Jak tenhle problem chcete vyresit?

Proč by to nešlo?

V čem vidíte problém?

Realita tj. že je to nepoužitelné víme. Dotaz ale zněl proč. Odpověď že je moc ovladačů nevysvětluje nepoužitelný systém. Z linuxu je sice nemůžete pochopitelně vzít tak jak jsou, ale ve zdrojácích máte popis chování HW, takže portace není otázkou let, ale spíš týdnů.

Ale ja prece nemluvim o driverch apod.

Jen o tech "10000 radkach" samotneho mikrokernelu (jak rika wikipedie dela "threads, processes, pre-emptive multitasking, message-passing, protected memory, virtual memory management, soft real-time support, kernel debugging support, and console I/O").

Proc to trvalo 20 let a asi 5 portaci na ruzna dalsi reseni nez doslo k tomu, ze si pisi svuj GNU Mach a tedy konecne maji nejaky stabilni zaklad na kterem mohou stavet.

Protože akademici vyrostli na unixu – nejmonolitičtějším systému co existuje.

Hluboko pod kůží a v hlavě mají vypáleny principy unixu a monolitu.

Snažili se nevědomky uplatňovat principy monolitu a jejich mozek a znalosti jim překážely.

Úspěšný monolit mohl vzniknout až tehdy, když Microsoft vytvořil obchodně úspěšný konkurenční koncept, který se velmi masově rozšířil, neudělaný na unixových základech – a tím donutil mozky lidí zjistit, že neexistuje jen unix koncept.

Obecně si myslím, že lidé nepoznající nic jiného, než unix prostě nejsou schopni úspěšné mikrojádro naimplementovat. Stráví mnoho let zjišťováním, že tudy ne.

Čím více toho pouze o unixu a Linuxu víte, tím méně jste disponováni napsat kvalitní mikrojádro, či napsat mikrojádro vůbec. Chybí vám nadhled.

Mohu se zeptat na slovo 'nepoznající'? Nějak mi nejde do hlavy.

Z hlediska jazykového mi v psaných i mluvených projevech v dnešní době nejde do hlavy mnohem více věcí. Toto bych skoro označil za to nejmenší - autorovi se evidentně hodil nějaký transgresivní tvar, ale protože neví, že čeština takovými tvary už disponuje (nebo je neumí používat), vymyslel si svůj patvar.
Neschopnost logicky souvětí rozčlenit pomocí interpunkčních znamének, rozlišit mě/mně, ni/ní, ji/jí, jež/jenž, s/z atp. už dnes beru jako snahu autorů takových textů udržovat mou pozornost - autoři "záměrně" píší něco jiného než myslí a je na mně, abych k textu přistupoval taky trochu aktivně a dešifroval to. :-)
Stejný přístup pak bohužel mají i k jazykům programovacím a pak se člověk diví, že programy padají jak hrušky na podzim.

Zaujala mne informace o tom, že se používal procesor Motorola 68000 - ten ale nemá ochranu paměti. Tak to tedy bylo:

1) Jednotlivé procesy byly teoreticky oddělené, ale v praxi ne
2) K 68000 se používal další čip (tuším, že existoval), který ochranu paměti zajišťoval
3) Nepoužívala se 68000, ale vyšší procesor z té řady, který už MMU měl

NeXT používal 68030 s integrovanou MMU.

Jo, takže věta článku "o Hurdu, který stále ještě vyžadoval počítač s procesorem Motorola 68000" je nepřesná.

Mam takovy pocit, ze v tom clanku je tech nesmyslu vic ... treba ta pasaz, kde si autor plete address spacy a protection ringy ...

MMU chip existoval az k 68010, ale moc povedena kombinace to nebyla (takze se pouzival az k 68020)

Jednoúlohový systém je z principu rychlejší než víceúlohový. Stejně tak mikrojádro se nadřazenými démony je z principu pomalejší než komplexní monokernel - jednoduše proto, že mikrojádro musí řešit mnoho dalších věcí a složitějším způsobem než monokernel. Ale i přes toto tvrzení jsem si jist, že cesta dalšího vývoje půjde směrem k mikrokernelu. Důvody mám dva. Jednak bezpečnost běhu jednotlivých procesů a za druhé stálý nárůst všeho možného HW (takže se domnívám že stále rostoucí jádro je nadále neudržitelné).
S tvrzením že víceprocesorové systémy (či cpu s více jádry) snáze pracují s mikrojádrem bych si příliš jistý nebyl. Obecně běh jádra je časově zanedbatelný proti běhu aplikace (resp. by to tak mělo být) proto je celkem jedno jak dobře jde navláknovat běh jádra, ale podstatné je, jak se mi podaří řešit paralelní běh aplikací. Zde velké rozdíly mezi mikrojádrem a monokernelem nevidím.

Běh jádra vůbec není časově zanedbatelný. Třeba veškeré čtení dat z disku jde přes jádro, stejně tak veškerá interakce s uživatelem (obrazovka, klávesnice, myš). To všechno lze paralelizovat, čímž se výkon systému na vícejaderných strojích dost razantně zvýší, proto se v Linuxu tak pracně odstraňoval BKL a proto se tam teď řeší bezzámkové cache. Něco, co by v mikrojaderné architektuře nikdy nevzniklo, protože tam se tyhle problémy řeší pomocí MMU (hardware).

Kolik má podle vás typický stroj procent CPU času v kernelu?

Co znamená "razantně" zvýší?

Jak podle vás MMU řeší synchronizaci cache?

Běžně asi jednu pětinu času, který využije příslušný proces, u virtualizace klidně i přes polovinu. Oboje je fakt hodně. Navíc se to týká všech procesů, takže nepatrné zrychlení jádra výrazně zrychlí celý systém.

Tak třeba pokud odstraníte globální zámek (BKL), který v mikrojádrech nemůže být by design, tak se rychlost zvýší až tolikrát, kolik máte jader.

Tak, že příslušné stránky se označí jako COW, případně pouze pro čtení, takže je můžete číst bez zamykání a nikdo vám je během čtení nezmění. Bez MMU to lze dělat podobně, ale je nutné provádět full memory barriery.

BKL je problém synchronizace. U mikrokernelu se zamykání řeší už ve stádiu návrhu. U NT taky. U Linuxu se to řešilo tak, že Linus najprve přišel s BKL, protože nerozumí designu a protože se to tak velmi snadno píše. A pak se všichni dlouhá léta snažili BKL odstranit. Moc se to ale nepovedlo :/

FYI, za BKL je zodpovedny Alan Cox. Navic, v roce '96 kdy prisla podpora pro SMP byly viceprocesorove pocitace asi tak bezne jako vysokorychlostni pripojeni k internetu, takze neni divu, ze to extra neresili.

BKL není jen věc podpory SMP. Je to problém i pro latency. A pokud jsem si všimnul, tak Linux uměl od začátku jen jediný proces v režimu jádra, jako kdysi nejstarší UNIXy. BKL je pouze důsledek návrhu (resp. absence návrhu).

> BKL je pouze důsledek návrhu (resp. absence návrhu).

Podle mě tento sarkasmus není na místě. Uvědomte si, že Linux vznikal v době, kdy víceprocesorové stroje byly doménou mainframů a superpočítačů, a v oblasti PC pouze exotů jako byl Intergraph (pamatujete někdo?).

Pokud byste měl na výběr udělat systém rychle, ale bez podpory více procesorů, a získal za to použitelnost na většině běžných zařízení, a tím větší rozšíření, a tím víc vývojářů, a tím po několika cyklech dostatek pracovní síly na reimplementaci, a naproti tomu udělat systém "pořádně" a pomalu s nedostatkem vývojářů, co byste si vybral? Přitom tehdy ani nebylo jasné jestli vývoj půjde k opravdu symetrickým multiprocesorům, nebo třeba k nějakým asymetrickým koprocesorům (jako je dnes Cell nebo různé APU architektury).

BKL umožnil _postupné_ zavedení podpory víceprocesorových systémů, a z těch míst kde opravdu vadil zmizel _dávno_ předtím, než se tyhle systémy začaly být masově rozšířené. Přitom ale už dlouho je Linux škálovatelnější než jiné systémy, které s paralelismem počítaly od začátku (Solaris, Windows NT).

Podle mě BKL bylo ve své době správné rozhodnutí.

Bylo by zajímavé podívat se z hlediska škálovatelnosti na mikrokernelové systémy. Kolik serverů v HURDu nebo v QNX umí využít víc než jedno jádro? Mají dnešní mikrokernely udělané fronty zpráv tak, aby bez zamykání mohlo více serverů číst z front události (jako to umožňují dnešní multiqueue síťové karty)? A umožňuje dnešní mikrokernel aby jeden klientský proces zařazoval požadavky na konkrétní server do fronty tak, aby se všechny požadavky jednoho klienta zpracovával ten server pořád na tom stejném CPU jádře? V monolitickém systému je to triviální - ty "požadavky" jsou volání funkce, které běží v tomtéž kontextu, a tedy obvykle na tomtéž jádře. Podle mě fronta zpráv serveru na většině dnešních mikrokernelů bude taková pěkná obdoba BKL.

Jak došlo na BKL? Linus psal terminálový emulátor, ke kterému bylo potřeba pár funkcí, a nakonec mu z toho vylezl minimalistický OS. Napsal ho podle manuálů komerčních unixů, nad designem moc nepřemýšlel. Vizte jeho slova:
http://groups.google.com/group/comp.os.minix/msg/b813d52cbc5a044b

Bohužel design OS se později těžko opravuje. Implementace threadingu použitelným způsobem (NPTL) byla uvedena až po 12 letech v kernelu 2.6, po obrovském úsilí. I tak je výsledek slabý ve srovnání s NT i Solarisem. Při slušném návrhu by nebyl problém threading implementovat ihned, nebylo by to moc práce navíc. Podobně bylo možné napsat kernel od začátku preemptivní, a ne pracně dodělávat po všech stránkách špatný hack jménem PREEMPT_VOLUNTARY, případně dokonce PREEMPT, na který si snad dodnes netroufla žádná major distribuce.

Ohledně škálovatelnosti Linuxu to vidíte velmi optimisticky.

BTW u koprocesorů je zajímavá možnost psát v .NETových jazycích, překládat je do CIL bytecode, a ten pak překládat dynamicky do strojáku. To může vést k tomu, že CIL bytekód webového nebo mailového serveru přeložíte podle konfigurace čistě pro CPU, nebo kus pro CPU a kus pro inteligentní síťovou kartu, nebo třeba pro kombinaci CPU+GPU. MS na to má pěkný research projekt nad Singularity. Jsem zvědavý na komerční využití. Třeba budou za pár let řadiče RAIDu běžet část kódu FS.

Napsat reentrantní server přece není technicky problém. Řešení fronty také není větší problém, nakonec totéž úspěšně řeší většina SMP kernelů (a fakt nevidím důvod, aby to vedlo na giant lock). A zařazování požadavků na konkrétní server a CPU je o optimalizaci scheduleru. Odesilatele požadavku přece znáte, takže víte, na kterém CPU běží. Pro cc:NUMA navíc můžete použít metriky: kolik stojí z daného CPU přístup k dané části paměti, danému host bridge atd - má to podporu i v ACPI pomocí tabulek SRAT a SLIT.
Mikrokernely mají samozřejmě vyšší overhead než jiné architektury. Ale zase se snáze udržují a jsou spolehlivější. Přitom existuje řada různých přístupů. Viz NT kernel s vybranými servery běžícími z důvodu výkonu v kernel mode (hlavní výhodou je modularita a škálovatelnost), případně Singularity se Software Isolated Processes, které zásadním způsobem zmenšují overhead mikrokernelu.

> Linus psal terminálový emulátor

Nic o emulátoru v tom článku není. Linus psal operační systém.

> Bohužel design OS se později těžko opravuje.

Právěže ne. Vývojový model Linuxu je přímo postaven na tom, že lepší je mít aspoň nějaký kód teď a opravit ho až někoho fakt bude štvát, a ne čekat 20 let na ideální kód jako HURD nebo sice méně než 20 let, ale pak se zavazovat ke kompatibilitě nekonečně dlouho jako Solaris nebo NT.

> Implementace threadingu použitelným způsobem
> (NPTL) byla uvedena až po 12 letech v kernelu
> 2.6, po obrovském úsilí.

Opět je vidět, že nevíte o čem mluvíte. Implementace threadingu v kernelu se jmenuje clone() a je v kernelu už od 2.2 nebo 2.0. A implementace byla naprosto triviální. NPTL je jedna z implementací rozhraní POSIX threads pro user-space. Na podpoře vláken v kernelu je docela nezávislá.

> Podobně bylo možné napsat kernel od začátku
> preemptivní, a ne pracně dodělávat po všech
> stránkách špatný hack jménem PREEMPT_VOLUNTARY,
> případně dokonce PREEMPT, na který si snad
> dodnes netroufla žádná major distribuce.

Bylo to sice možné, ale dopadli bychom jako HURD - nikdy by takový systém nevznikl. Nepreemptivní jádro se totiž dá napsat výrazně snadněji.

Ohledně PREEMPT - nevím po kterých všech stránkách je špatný, podle mě je prudce elegantní. Využívá totiž zajímavého faktu, a to že kernel byl mezitím portovaný na SMP systémy, a tedy do sekcí u kterých vadí paralelní běh byly dopsány zámky nebo BKL. A PREEMPT pak není nic jiného než povolit přepnutí kontextu i na UP v situaci, kdy nedržíte žádný zámek (a tedy kódu nevadí ani skutečný paralelismus SMP, natož umělý vyvolaný přepnutím kontextu).

> MS na to má pěkný research projekt nad
> Singularity. Jsem zvědavý na komerční využití.

Já taky :-) Podle mě žádné nebude.

> Třeba budou za pár let řadiče RAIDu běžet část
> kódu FS.

Tady už jsme byli. Říká vám něco pojem I2O?
Neprosadilo se to. A dneska by to z důvodů lokality dat mělo ještě větší problém než tehdy.

> Napsat reentrantní server přece není technicky
> problém. Řešení fronty také není větší problém,
> nakonec totéž úspěšně řeší většina SMP kernelů
> (a fakt nevidím důvod, aby to vedlo na giant
> lock).

Technicky to není problém. Teoretici vám vždycky vysvětlí, že teoreticky může být mikrokernel stejně rychlý jako monolitický kernel. Praxe ovšem pokulhává. Který současný mikrokernel má servery využívající více CPU?

Fronta ovšem obvykle na globální zámek vede, pokud se nechcete vzdát garance pořadí požadavků v té frontě. Což by zase znamenalo úplně nový návrh API pro zasílání zpráv v tom mikrokernelu.

> zařazování požadavků na konkrétní server a CPU
> je o optimalizaci scheduleru.

Znovu: teoreticky to jde, v praxi to nikdo nedělá. A přitom v monolitickém kernelu to máte zadarmo: když více vláken volá tu stejnou funkci, triviálně běží požadavek každého vlákna na tom svém CPU.

NT není mikrokernel. Aspoň ve srovnání s Linuxem ze stejné doby mi vždycky ten NT "mikrokernel" (plus hal.exe) vyšel větší než monolitický Linux. NT je monolitický kernel. Některé části NT jsou v kernelu a jiné systémy je mají mimo kernel (grafika) a některé zase naopak.

> Ohledně škálovatelnosti Linuxu to vidíte velmi optimisticky.

Tohle jsem přehlédl, pardon :-)

Škálovatelnost Linuxu: top500.org mi říká, že ohledně škálovatelnosti použitelné a použité v praxi nikdo nic lepšího než Linux nevymyslel.

> http://groups.google.com/group/comp.os.minix/msg/b813d52cbc5a044b

> Třeba budou za pár let řadiče RAIDu běžet část kódu FS.

Tak jsem se do výše citovaného threadu začetl ještě víc, a je tam zmiňovaný SCSI řadič NCR, který taky mohl vykonávat kusy kódu dodané operačním systémem. To je rok 1991 prosím. Tak se mi zdá že Microsoft vynalézá dvacet(*) let staré kolo.

(*) minimálně; řekl bych že mainframy tohle mohly mít ještě dalších dvacet let zpátky.

Vzdycky se leknu jestli ctu dobre, protoze to jak si temer vzdy ohnete pravdu tak aby z toho vysli win dobre me zarazi a pak si vsimnu autora, usmeju se a nereaguju.
Vy to v podstate delate take, ale az po tom co vam nekdo Vasi pravdu vyvrati.. Pak uz se k vlaknu diskuse nevracite.

Z mého pohledu ohýbají pravdu lidé jako vy, tak aby jim vyšlo něco jiného. Některé věci jsou holt otázkou intepretace.
To je zajímavé. Když svůj názor na věc v diskusi dál rozvádím, tak jsem ten špatný, který začíná flame war. Když nemám trpělivost a čas na všechno odpovídat, tak jsem ten špatný, kdo z diskuse utíká, když mu jeho pravdu vyvrátí. Co z toho plyne? Vždycky je někdo nespokojený :)

Nikdy se nezavdecite vsem.. Spis bych rekl opak, vzhledem k tomu ze jste pro-win(nic proti win, taky je pouzivam a uz ani tolik nenadavam jako tomu bylo u vist) uzivatel na serveru plnem linux fanatiku (doufam, ze tech tu neni prilis, ale ozve se vzdy nekdo) ;)

Zajímalo by mně, proč Posix a Unix brání napsat efektivní mikrojádro?
Jinak si myslím, že Hurd ztroskotal právě na tom, že sa snažili vymyslet dokonalý návrh (rozhraní), místo aby se soustředili spíš na praktickou použitelnost jako Linux. Žádný návrh nebude nikdy dokonalý. A proto Hurd nikdy nezvítězí.