Mikrokernel

Mikrokernel alebo mikrojadro je minimalistický kernel (jadro) operačného systému počítača, ktorý poskytuje iba základné služby operačného systému (systémové volania), kým iné služby (bežne poskytované kernelmi) namiesto neho (a v spolupráci s ním) poskytujú user-space programy nazývané servery. Mikrokernely zvyčajne poskytujú služby ako správa adresného priestoru, vlákien a komunikáciu medzi procesmi, ale nie napríklad podporu sietí či zobrazovacích zariadení.

Grafická schéma mikrokernelu

Neskoršie rozšírenia tohto konceptu viedli k novým architektúram ako nanokernely, exokernely a abstrakčné vrstvy hardvéru (HAL).

Výhody konceptu mikrojadra pri návrhu systémov:

(a) pridanie novej služby nevyžaduje modifikáciu jadra,
(b) je principiálne bezpečnejšie, keďže viac operácií sa vykonáva v užívateľskom režime ako v režime jadra,
(c) jednoduchší dizajn a funkcionalita zvyčajne má za následok spoľahlivejší operačný systém.
Štruktúra založená na monolitickom a mikrokernelovom operačnom systéme

"'Mikrokernel'" je minimálny počítačový operačný systém kernel ktorý, vo svojej najčistejšej podobe, neposkytuje takmer žiadne služby operačného systému, iba "mechanizmus" potrebný na implementáciu takých služieb ako je nízko úrovňový adresový priestorový manažment, vláknový manažment a vnútro procesovú komunikáciu (IPC). Ak mikrokernel rozlišuje medzi kernelovským a používateľským módom, tak mikrokernel je jedinou časťou systému vykonávanou v kernel móde. Skutočné služby operačného systému sú poskytované servermi "používateľského módu". Tie zahŕňajú ovládače zariadenia, protokolový zásobník, súborový systém a kód používateľského rozhrania.

Tieto výsledky v systémovej štruktúre sa drasticky odlišujú od monolitických kernelov na masovom trhu. Tento má zvyčajne vertikálne delenú štruktúru, ktorá je založená na tom, že služby sú aplikáciám prideľované na základe systémového volania, ktoré je pre každú službu špecifické. Kým systém založený na mikrokerneli má horizontálnu štruktúru charakteristickú získavaním systémových služieb tým, že vykonajú IPC volanie adresované konkrétnemu serveru.

Mikrokernely majú blízky vzťah s exokernelom. Veľa spoločného majú aj s hypervisormi, ale nerobia si nárok na minimalitu, a špecializujú sa na podporu virtuálnych strojov. L4 mikrokernel je často používaný ako hypervisor, ktorý poukazuje na to, že mikrokernel je možnou implementáciou hypervisor-u. Pojem nanokernel je historicky používaný na odlíšenie od skorších mikrokernelov, ktoré obsahovali aktuálne systémové služby, ale "princíp minimality" použitý Jochen Liedtkem v schéme L4 mikrokernelu naznačuje, že tieto termíny majú rovnaký význam; mikrokernel je moderná terminológia.

Úvod

Prvé kernely operačného systému boli malé aj kvôli limitovanej pamäti počítačov. Ako schopnosti počítačov rástli, množstvo zariadení, ktoré musel kernel riadiť, rástlo tiež. Prvotné verzie UNIXov mali kernely strednej veľkosti, aj keď obsahovali nastavenia ovládačov a manažérov systémových súborov. Keď sa veľkosti adries zväčšili z 16 na 32 bitov, dizajn kernelu nemusel byť viac preplnený hardwareovou architektúrou a kernely začali narastať (Pozri História Unixu).

Berkeley Unix (BSD)-om začala éra veľkokapacitných kernelov. Navyše k vykonávaniu základného systému skladajúceho sa z CPU, diskov a tlačiarní, BSD začal pridávať prídavne súborové systémy, kompletný TCP/IP sieťový systém a množstvo "virtuálnych" zariadení, ktoré umožnili existujúcim programom pracovať neviditeľne (na pozadí) cez sieť. Tento rast pokračoval niekoľko desaťročí, čo malo za následok vznik kernelov s miliónmi riadkov zdrojového kódu. Následkom tohto rastu kernely boli viac náchylné k chybám a stávali sa stále viac a viac náročné na údržbu.

Mikrokernel bol skonštruovaný tak, aby sa vysporiadal s narastajúcou veľkosťou kernelov a potiažami, ktoré prichádzali s nimi ruka v ruke. Teoreticky, mikrokernelova štruktúra poskytla ľahšiu správu kódu vzhľadom na jeho delenie na služby používateľského priestoru. Toto taktiež počítalo s narastajúcou bezpečnosťou a stabilitou vychádzajúc zo zredukovaného množstva kódu prebiehajúceho v kernel móde.

Napríklad, ak sieťová služba spadla kvôli pretečeniu buffera, iba pamäť sieťovej služby by bola narušená a ostatok systému by zostal neporušený. V tradičnom monolitickom kerneli pretečenie by mohlo narušiť pamäť ostatných ovládačov a možno aj kernel samotný, ktorý by mohol spôsobiť zrútenie celého systému.

Vnútro-procesová komunikácia

Vnútro-procesová komunikácia (IPC) je nejaký mechanizmus, ktorý umožňuje oddeľovanie procesov na to, aby mohli spolu komunikovať obyčajne posielaním správ. (Zdieľaná pamäť je v úzkom slova zmysle tiež medziprocesovým mechanizmom komunikácie, ale skratka IPC sa zvyčajne týka iba prechodu správ, a to je to, čo je obzvlášť relevantné pre mikrokernely.) To dovoľuje operačnému systému, aby bol vystavaný zo skupiny malých programov nazývaných servery, ktoré sú používané ďalšími programami v systéme volanými cez IPC. Väčšina alebo všetky podpory pre periférny hardware je ovládaný takýmto spôsobom, so servermi pre ovládače zariadení, súbory sieťových protokolov, súborové systémy, grafiky, atď.

IPC môže byť synchrónny alebo asynchrónny. Asynchrónny IPC je analogický so sieťovou komunikáciou: odosielateľ zasiela správu a pokračuje vo vykonávaní. Príjmateľ overuje dostupnosť správy pokúšaním sa o jej prijatie, alebo je na to upozornený prostredníctvom oznamovacieho mechanizmu. Asynchrónne IPC vyžaduje od kernelu, aby udržoval buffery a fronty na správy, a zaoberá sa pretečeniami bufferu; to tiež vyžaduje dvojité kopírovanie správ (odosielateľ kernelu a kernel príjmateľovi). V synchrónnom IPC, prvá strana (odosielateľ príjmateľovi) blokuje pokiaľ druhá strana nie je pripravená vykonať IPC. Nevyžaduje to ukladanie do zásobníka ani viaceré kópie, ale bez akýchkoľvek pochýb, takéto konflikty môžu robiť programovanie zložitým. Väčšina programátorov preferuje asynchrónne posielanie a synchrónne príjmanie.

Prvá generácia mikrokernelov podporovala synchrónne aj asynchrónne IPC a pripúšťala nízku výkonnosť IPC. Jochel Liedtke označil dizajn a implementáciu IPC mechanizmov ako základný dôvod tejto slabej výkonnosti. V jeho L4 mikrokerneli zaviedol nové techniky, ktoré viedli k výnosu z veľkosti redukcii v IPC výdavkoch.[1] Tieto zahŕňajú IPC systémové volanie, ktoré podporuje posielanie rovnako ako získavanie operácií, robenie všetkých IPC synchrónne a umožňujú, aby registrami prechádzalo čím viac dát. Navyše, Liedtke predstavil koncept "priameho prepnutia procesu", keď počas vykonávania IPC sa spraví (neúplné) prepnutie kontextu priamo od odosielateľa k príjmateľovi. Ak, ako v L4, časť alebo všetky správy prešli registrami, tieto premiestnenia sa v registerovej časti správy nachádzajú bez akýchkoľvek kópií. Okrem toho, vrchné volanie plánovača sa obíde; to je zvlášť prospešné vo všeobecnom prípade kde IPC je používané v RPC tvare volaním servera klientom. Ďalšia optimalizácia, volaná "lenivé plánovanie", sa vyhýba kríženiu plánovania radov počas IPC, tým že necháva vlákna blokované počas IPC v pripravenom rade. Keď je raz plánovač vyvolaný, premiestňuje také vlákna do vhodného čakajúceho radu. Ako v mnohých prípadoch vlákno sa stane odblokovaným pred ďalším vyvolaním plánovača, to spôsobí uloženie dôležitej práce. Podobné prístupy boli odvtedy prijaté QNX a Minix 3.

V klient-server systéme, väčšina komunikácie je v podstate synchrónna, aj keď používa asynchrónne primitívy, ako typická operácia je volanie servera klientom a potom čakanie na odpoveď. To si tiež pre seba požičiava výkonnejšie implementácie, moderné mikrokernely spravidla nasledujú vedenie L4 a poskytujú iba synchrónne IPC primitíva. Asynchrónne IPC môže byť implementované na vrchu použitím pomocníka vlákien. Ale, verzia L4 rozmiestnená v komerčných produktoch ukázala aké nevyhnutné je pridať asynchrónny oznamovací mechanizmus pre lepšiu podporu asynchrónnej komunikácie. Tento mechanizmus podobný signálu neobsahuje dáta a preto nevyžaduje vyrovnávaciu pamäť v kerneli.

Keďže synchrónne IPC blokuje prvú stranu pokiaľ ďalšia nie je pripravená, neobmedzené použitie môže ľahko viesť k uviaznutiu. Navyše, klient môže ľahko inštalovať útok popretie služby na serveri poslaním žiadosti a pritom sa nikdy nepokúsiť získať odpoveď. Takže synchrónne IPC musí poskytnúť prostriedky na prevenciu nekonečného blokovania. Veľa mikrokernelov poskytuje timeouty na IPC volania. ktoré limitujú čas blokovania. V praxi, citlivo vybrať hodnoty timeout je ťažké a systémy takmer nevyhnutne použijú nekonečné timeouty pre klienty a nulové timeouty pre servery. Ako dôsledky, trendom je neposkytovanie ľubovoľných timeoutov, ale iba znamenie, ktoré naznačuje, že IPC by mohlo ihneď zlyhať ak partner nie je pripravený. Tento prístup efektívne poskytuje výber dvoch timeout hodnôt nula a nekonečno. Posledné verzie L4 a Minix sa uberali touto cestou (staršie verzie L4 používali timeouty ako ich používa QNX).

Servery

Mikrokernel servery sú v podstate daemon programy ako ostatné, okrem toho kernel podporuje niektoré z ich privilégií na interakciu s časťami fyzickej pamäte, ktoré sú ináč mimo dosahu pre väčšinu programov. Toto umožňuje niektorým serverom, hlavne ovládačom zariadení, interakciu priamo s hardwarom.

Základná séria serverov so zameraním na mikrokernel zahŕňajú servery súborového systému, servery ovládačov zariadení, servery sietí, servery zobrazenia a servery rozhrania používateľského zariadenia. Táto séria serverov (získané z QNX) poskytuje zhruba sériu služieb ponúkaných monolitickým UNIX kernelom. Nevyhnutné servery sa štartujú pri štartovaní systému a ponúkajú slúžby, také ako súbor, sieť a prístup zariadenia až po obyčajnné programové aplikácie. S takými servermi bežiacimi v prostredí používateľskej aplikácie, vývoj serverov je podobný vývoju obyčajnej aplikácie, skôr než postaviť a zaviesť proces, ktorý je potrebný pre vývoj kernelu.

Dodatočne, veľa "padnutí" môže byť opravených jednoduchým zastavením a reštartovaním servera. (V obyčajnom systéme, padnutie v hociktorom kernel rezidentnom kóde by malo za následok padnutie celého stroja, vynútený reboot.) Ale, časť systémového stavu sa stratí s chybovým serverom, preto tento prístup vyžaduje aplikácie na vyrovnanie sa so zlyhaním. Dobrým príkladom je server zodpovedný za TCP/IP spojenie: Ak je tento server reštartovaný, aplikácie zažijú "stratenie" spojenia, normálny jav v sieťovom systéme. Pre ostatné služby, zlyhanie je menej očakávané a môže vyžadovať zmeny v kóde aplikácie. Pre QNX, schopnosť reštartu je ponúkaná ako QNX Vysoko Dostupný Toolkit (pomocné programové vybavenie).[2]

Kvôli snahe spraviť všetky servery reštartovateľné, niektoré mikrokernely sa koncentrovali na pridávanie rôznych databázam podobných techník ako transakcie, repliky a checkpointing (auto-zápis kontrolných bodov) kvôli zachovaniu dôležitých stavov po reštartovaní jedného serveru. Príkladom je ChorusOS, ktorý bol ohrozovaný aplikáciami vysokej kvality v telekomunikačnom svete. ChorusOS obsahoval funkcie, ktoré umožňovali každému "správne napísanému" serveru to, aby bol kedykoľvek reštartovaný s tým, že klienty, ktoré využívali tieto servery by boli pozastavení do doby, kým by sa server znovu nedostal do pôvodného stavu.[chýba zdroj] Ale, také rysy kernelu sú nekompatibilné s princípom minimality a preto nie sú poskytované v moderných mikrokerneloch, namiesto spoliehania sa na vhodné protokoly užívateľskej úrovne.

Ovládače zariadenia

Ovládače zariadenia často uskutočňujú priamy prístup do pamäte(DMA), takže môžu písať na ľubovoľné miesta fyzickej pamäte, vrátane štruktúry nad dátami kernelu. Také ovládače preto musia byť dôveryhodné. Je všeobecne mylnou predstavou, že to znamená, že musia byť časťou kernelu. V skutočnosti, ovládač nie je sám o sebe veľmi dôveryhodný tým, že je časťou kernelu.

Pokiaľ beží ovládač zariadenia v používateľskom móde nie nevyhnutne zmenšuje poškodenie, ktoré zle správajúci sa ovládač môže spôsobiť, v praxi je to priaznivé pre stabilitu systému v prítomnosti buggy (skôr zákerných) ovládačov: narušenia v prístupe do pamäte samým kódom ovládača (ako protikladné zariadenie) môže byť stále chytené správou pamäťového hardwaru. Navyše, veľa zariadení nie je schopné DMA, ich ovládače môžu byť nedôveryhodné tým, že ich spustíme v používateľskom móde. Nedávno, zvyšujúci sa počet počítačových rysov IOMMUy, veľa z nich môže byť použitých na obmedzenie prístupu zariadenia do fyzickej pamäte.[3] (IBM sálový počítač mal IO MMU a odvtedy IBM System/360 Model 67 a System/370.) To tiež dovoľuje ovládačom používateľského módu stať sa nedôveryhodnými.

Ovládače používateľského módu sa v skutočnosti začali vyskytovať skôr než mikrokernely. Michiganský Terminálový Systém (MTS), v 1967, podporoval ovládače užívateľského priestoru, prvý operačný systém skonštruovaný s takouto schopnosťou.[4] Historicky, ovládače boli menším problémom, zatiaľ čo počeť zariadení bol malý a rozhodne dôveryhodný, takže mať ich v kerneli v zjednodušenom tvare a vyhýbať sa potenciálnemu vykonaniu problémov. To viedlo k tradičnému štýlu kernelovského ovládača v UNIX, Linux a Windows.[5] S bujnením rôznych druhov periférií, množstvo kódu ovládača sa vystupňoval a v modernom operačnom systéme dominuje kernel z hľadiska veľkosti kódu.

Základné komponenty a minimality

Keďže mikrokernel musí navyše povoliť výstavbu ľubovoľných služieb operačného systému, musí poskytovať niektoré základné funkcionality. Zahŕňa aspoň tieto:

  • nejaké mechanizmy na jednanie s adresovými priestormi – to je nutné na riadenie pamäťovej ochrany;
  • nejaké vykonavacie abstrakcie na riadenie alokácie CPU – poväčšine vlákna alebo aktivácie plánovača; a
  • vnútro-procesová komunikácia – vyžaduje vyvolať bežiace servery v ich vlastných adresových priestoroch.

Tento minimálny tvar bol vytvorený Brinch Hansen-ovým Jadrom, dohľad nad tým mal IBM operačný systém VM. Odvtedy to bolo sformalizované v Liedtkeho "princípe minimality":

Koncept je tolerovaný vo vnútri mikrokernelu iba ak je mimo kernelu t. j., dovolenie súťaženia implementácií, by zabránilo implementácii sytému mať potrebnú funkcionalitu.[6]

Všetko ostatné môže byť spravené v používateľskom programe, aj keď ovládače zariadení implementované ako používateľské programy môžu vyžadovať špeciálne privilégiá na prístup k I/O hardwaru.

Čo sa týka princípu minimality, rovnako dôležité pre dizajn mikrokernelu, je oddelenie zariadenia a politiky, toto umožňuje konštrukciu ľubovoľného systému na vrch minimálneho kernelu. Hocijaká politika vybudovaná v kerneli nemôže byť prepísaná na používateľskom leveli, a preto sú tu limity všeobecnosti mikrokernelov.[7] Politika implementovaná v serveroch používateľského levelu môže byť zmenená nahradením serverov (alebo ponechaním na aplikáciu nech vyberie medzi súperiacími servermi ponúkajúcimi podobné služby).

Pre efektívnosť, väčšina mikrokernelov obsahuje plánovače a časovače riadenia, pri nedodržaní princípu minimality a princípu separácie politiky od mechanizmu.

Štartovanie (booting) systému založenom na mikrokerneli vyžaduje ovádače zariadenia, ktoré nie sú časťou kernelu. Obyčajne to znamená, že sú balené s kernelom v boot image a kernel podporuje zavádzanie protokolu, ktorý definuje ako sú ovládače umiestnené a začínané. Niektoré mikrokernely to zjednodušujú umiestnením niektorých kľúčových ovládačov do vnútra kernelu (v rozpore s princípom minimality), LynxOS a orginál Minix sú príkladmi. Niektoré dokonca zahŕňajú aj súborový systém v kerneli na zjednodušenie zavádzania.

Hlavný komponent mikrokernelu je dobrý IPC systém. Pokiaľ sú všetky služby vykonávané programami používateľského módu, výkonný znamená, že komunikácia medzi programami je ešte nevyhnutnejšia než v monolitickom kerneli. Dizajn IPC systému vytvára alebo ničí mikrokernel. Aby bol efektívny, IPC systém nesmie mať iba nízke mimoriadne výdavky, ale tiež dobré vzájomné pôsobenie s CPU plánovačom.

Vykonávanie

Získavanie služieb je samo o sebe drahšie v systéme založenom na mikrokerneli ako v monolitickom systéme.[8] V monolitickom systéme, služby získané pomocou jedného systémového volania, ktoré požaduje dva prepínače módu (zmeny v procesoroch privilegovaného levelu). V systéme založenom na mikrokerneli, služby sú získavané posielaním IPC správy serveru a získavanie výsledkov v ďalšej IPC správe od serveru. Toto vyžaduje kontextový prepínač ak sú ovládače implementované ako procesy, alebo volanie funkcie, ak sú implementované ako procedúry. Navyše, podávanie aktuálnych dát serveru a späť môže mať za následok podstatné zväčšovanie mimoriadnych výdavkov, zatiaľ čo v monolitickom systéme kernel môže priamo pristupovať k dátam v klientských bufferoch.

Vykonanie je preto potenciálnym sporom v systémoch mikrokernelu. V skutočnosti, skúsenosti prvej generácie mikrokernelov takých ako Mach a Chorus ukázali, že systémy založené na nich podávali úbohé výkony.[9] Ale Jochen Liedtke ukázal, že výkonové problémy Machu boli výsledkom úbohého dizajnu a implementácie, a špeciálne Machova neúmerná cache stopa.[6] Liedtke demonštroval s jeho vlastným L4 mikrokernelom, že prostredníctvom opatrného dizajnu a implementácie, a špeciálne nasledovaním princípu minimality, IPC cena môže byť redukovaná viac než výnos veľkosti v porovnaní s Mach. IPC výkon L4 je stále neporaziteľný naprieč hranicami architektúr.[10][11][12]

Pokiaľ tieto výsledky demonštrovali, že úbohý výkon systémov založených na prvej generácii mikrokernelov nie je zástupcom druhej generácie kernelov tak ako L4, to neznamená žiadny dôkaz, že systémy založené na mikrokerneloch môžu mať dobrý výkon. Bolo ukázané, že monolitický Linuxový server spojený s L4 vyžaduje iba zopár percent mimoriadnych výdavkov oproti čistému Linuxu.[13] Ale, taký jednoserverový systém ukazuje iba zopár, ak vôbec nejaké výhody, výhody mikrokernelov sú údajne poskytnuté štruktúrovaním funkcionality operačného systému do oddelených serverov.

Existuje zopár komerčných multiserverových systémov, v jednotlivých realtime systémoch QNX a Integrita(operačný systém). Nekomplexné porovnanie vzájomného výkonu s monolitickými systémami bolo publikované pre multiserverové systémy. Okrem toho, vykonanie sa nezdá byť prvoradým záujmom pre tie komerčné systémy, ktoré namiesto toho aby vyzdvyhovali jednoduchosť voči robustnosti. Pokus o postavenie vysoko výkonného multiserverového operačného systému bol IBM Sawmill Linux projekt.[14] Ale tento projekt nebol nikdy dokončený.

Medzitým bolo ukázané, že ovládacie zariadenia používateľského levelu sa môžu priblížiť výkonom ovládačom kernelu dokonca aj pre vysoko priepustné, vysoko prerušované zariadenia ako Gigabit Ethernet.[15] Zdá sa, že to znamená nemožnosť existencie vysoko výkonných multiserverových systémov.

Bezpečnosť

O bezpečnostných výhodách mikrokernelu sa často debatovalo.[16][17] V súvislosti s bezpečnosťou, princíp minimality mikrokernelov je priamy dôsledok princípu najmenších privilégií, podľa ktorého by všetky kódy mali mať iba privilégiá potrebné na poskytnutie nutnej funkcionality. Minimality vyžadujú, aby systémová dôveryhodná výpočtová báza(TCB) bola udržiavaná minimálna. Keďže kernel (kód, ktorý sa vykonáva v privilegovanom móde hardwaru) je vždy časťou TCB, jeho minimalizovanie je prirodzene v dizajne bezpečnostného ovládača.

Takže, dizajn mikrokernelu bol použitý pre systémy navrhnuté ako aplikácie vysokej bezpečnosti, vrátane KeyKOS, EROS a vojenských systémov. V skutočnosti common criteria (CC) v najvyššom bezpečnostnom leveli (EAL7) mali jasné požiadavky, aby cieľ ohodnotenia bol “jednoduchý”, čiže uznanie praktickej nemožnosti vytvorenia pravej dôveryhodnosti pre systém ako celok.

Nedávna práca na mikrokerneloch je zameraná na formálnych špecifikáciách kernel API, a formálne dôkazy bezpečnosti vlastností API. Prvým príkladom tohto matematického dôkazu sú obmedzenia mechanizmu v EROS, založené na zjednodušenom modeli EROS API.[18] Nedávno, pomocou uplného súboru dôkazov kontroly stoja(machine-checked) boli predvedené vlastnosti ochranného modelu seL4 verzie L4.[19]

Niektoré projekty idú ešte ďalej, sú namierené na celkové formálne overenie, t. j. matematický dôkaz, že implementácia kernelu je zhodná s jeho špecifikáciou, čo potom poskytuje garanciu, že vlastnosti overené o API skutočne platia pre ozajstný kernel. Tento stupeň dôvery ide dokonca za CC EAL7. O také dôkazy sa pokúšali pre Coyotos a seL4. Doplňam, že sa takovéto dôkazy podarilo realizovať pro mikrokernel Fiasco a najmä pre seL4 viď článok na české Wikipédii.

Pozri aj

Poznámky
  1. LIEDTKE, Jochen. Proceedings of the fourteenth ACM symposium on Operating systems principles. Asheville, Severná Karolína : ACM, 1994. ISBN 0-89791-632-8. DOI:10.1145/168619.168633 Kapitola Improving IPC by kernel design, s. 175–188. (po anglicky)
  2. QNX High Availability Toolkit
  3. WONG, William. I/O, I/O, It's Off To Virtual Work We Go. Electronic Design, 27. apríl 2007. Dostupné online.
  4. ALEXANDER, Michael T. Proceedings of the November 16-18, 1971, fall joint computer conference. Las Vegas : ACM, 1971. DOI:10.1145/1478873.1478951 Kapitola Organization and features of the Michigan terminal system, s. 585–591. (po anglicky)
  5. LIONS, John. Lions' commentary on Unix 6th edition: with source code. San José : Peer-to-Peer Communications, 1996. ISBN 978-1-57398-013-5. (po anglicky)
  6. LIEDTKE, Jochen. Proceedings of the fifteenth ACM symposium on Operating systems principles. New York : ACM, 1995. ISBN 0-89791-715-4. DOI:10.1145/224056.224075 Kapitola On µ-Kernel Construction, s. 237–250.
  7. LIEDTKE, Jochen. Towards Real Microkernels. Communications of the ACM, september 1996, roč. 39, čís. 9, s. 70–77. DOI: 10.1145/234215.234473. (po anglicky)
  8. Previously cited
  9. CHEN, J. Bradley; BERSHAD, Brian N. Proceedings of the fourteenth ACM symposium on Operating systems principles. New York : ACM, 1994. ISBN 0-89791-632-8. DOI:10.1145/168619.168629 Kapitola The impact of operating system structure on memory system performance, s. 120–133. (po anglicky)
  10. LIEDTKE, Jochen; ELPHINSTONE, Kevin; SCHÖNBERG, Sebastian, et al. The Sixth Workshop on Hot Topics in Operating Systems, 1997. Cape Cod, Massachusetts : IEEE, 1997-máj. ISBN 0-8186-7834-8. DOI:10.1109/HOTOS.1997.595177 Kapitola Achieved IPC performance (still the foundation for extensibility), s. 28–31. (po anglicky)
  11. GRAY, Charles; CHAPMAN, Matthew; CHUBB, Peter, et al. USENIX 2005 Annual Technical Conference, General Track. [s.l.] : [s.n.], 2005. Kapitola Itanium—A System Implementor's Tale, s. 265–278. (po anglicky)
  12. VAN SCHAIK, Carl; HEISER, Gernot. Proceedings of the 1st International Workshop on Microkernels for Embedded Systems. Sydney : NICTA, 2007-január. Kapitola High-performance microkernels and virtualisation on ARM and segmented architectures, s. 11–21. (po anglicky)
  13. HÄRTIG, Hermann; HOHMUTH, Michael; LIEDTKE, Jochen, et al. [s.l.] : [s.n.], 1997-október. ISBN 0-89791-916-5. DOI:10.1145/268998.266660 Kapitola The performance of μ-kernel-based systems, s. 66–77.
  14. GEFFLAUT, Alain; JAEGER, Trent; PARK, Yoonho, et al. Proceedings of the 9th workshop on ACM SIGOPS European workshop: beyond the PC: new challenges for the operating system. Kolding, Dánsko : ACM, 2000. ISBN 1-23456-789-0 Chybné ISBN. DOI:10.1145/566726.566751 Kapitola The SawMill multiserver approach, s. 109–114. (po anglicky)
  15. LESLIE, Ben; CHUBB, Peter, et al. User-Level Device Drivers: Achieved Performance. Journal of Computer Science and Technology, september 2005, roč. 20, čís. 5, s. 654–664. DOI: 10.1007/s11390-005-0654-4. (po anglicky)
  16. Tanenbaum, Andrew S., Debata Tanenbaum-Torvalds: Part II
  17. TANENBAUM, Andrew S; HERDER, Jorrit N; BOS, Herbert. Can We Make Operating Systems Reliable and Secure?. Computer, máj 2006, roč. 39, čís. 5, s. 44–51. Dostupné online. DOI: 10.1109/MC.2006.156. (po anglicky)
  18. SHAPIRO, Jonathan S; WEBER, Sam. Proceedings of the 2000 IEEE Symposium on Security and Privacy. Berkeley, Kalifornia : IEEE, 2000. ISBN 0-7695-0665-8. DOI:10.1109/SECPRI.2000.848454 Kapitola Verifying the EROS confinement mechanism, s. 166–176. (po anglicky)
  19. ELKADUWE, Dhammika; KLEIN, Gerwin; ELPHINSTONE, Kevin. Verified Software: Theories, Tools, Experiments. Berlin : Springer, 2008. ISBN 978-3-540-87872-8. DOI:10.1007/978-3-540-87873-5_11 Kapitola Verified Protection Model of the seL4 Microkernel, s. 99–114. (po anglicky)

Ďalšie čítanie
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.