thumb|right|Grafická schéma mikrokernelu
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í.
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.
thumb|Š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. Jochen 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. 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).QNX High Availability Toolkit
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. 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.