Az elmúlt évtizedekben a hagyományos kernelfajták mellett több olyan, kifejezetten kísérleti célú kernelarchitektúra is született, amelyek teljesen más szemszögből közelítik meg az operációs rendszer magját. Ezek a megoldások abban különböznek egymástól, hogy mit tartanak „kernelfeladatnak”, és mennyi mindent hagynak a rendszer többi részére: van, amelyik a végletekig lecsupaszítja a magot, más pedig épp a feladatok újrafelosztásával próbál rugalmasabbá vagy skálázhatóbbá tenni mindent. A PingvinBázis blog 5. száma ezekre a nem mindennapi kernelmodellekre fókuszál. Minden fejezetben végigvesszük az adott koncepció alapötletét és filozófiáját, a történeti hátterét, a gyakorlati példáit, és azt is, hogy technológiailag miért érdekes vagy fontos. Ez a bejegyzés kifejezetten a kutatási célú kernel típusokra koncentrál; ha a klasszikus kernelarchitektúrákról is szeretnél átfogó képet, nézd meg a cikkel együtt megjelenő videónkat a YouTube-on.
Tartalomjegyzék
Nanokernel: a mikrokernel extrém változata
Alapötlet és működés
A nanokernel kifejezés egy rendkívül kis méretű, minimalista rendszermagot jelöl. A szakértők gyakran úgy fogalmaznak, hogy a nanokernel lényegében egy lecsupaszított mikrokernel. Míg a mikrokernel is csak a legszükségesebb funkciókat hagyja a kernelben, a nanokernel ezt a minimalizmust még tovább viszi. A nanokernel nem valósít meg magas szintű hardverabsztrakciót, csupán a legalapvetőbb feladatokat látja el, például kezeli a CPU módváltásait és az interruptokat, biztosítja a memóriavédelem legalapvetőbb mechanizmusait. Minden más funkciót – az eszközmeghajtók működésétől a fájlrendszerig – külső komponensek (akár user módban futó folyamatok) valósítanak meg.
Ez azt is jelenti, hogy a nanokernelhez minden egyes hardver-erőforráshoz külön meghajtó vagy szolgáltatás szükséges, hiszen a kernel maga nem biztosít általános, hardverfüggetlen réteget. Például egy nanokernel rendszerben külön modul kezeli az időzítőt, a megszakításvezérlőt, a memóriakezelő egységet, ahelyett, hogy ezekhez egységes interfészt adna a kernel. A nanokernel tehát a lehető legkisebb mag, amely még éppen működőképes operációs rendszer gerincet alkot.
A nanokernel tervezési filozófiája az operációs rendszerek radikális decentralizációjára épít: a rendszermag itt nem egy központi irányító egység, hanem csupán a hardverrel való érintkezés legvékonyabb technikai rétege. Ebben a modellben a kernel teljesen mentes a hagyományos vezérlési logikától és algoritmusoktól, így hiányzik belőle a saját ütemező, az IPC-réteg vagy a belső memóriamenedzselő infrastruktúra is. A hardverrel való kommunikáció szigorúan technikai szinten marad: a kernel nem értelmezi a megszakítások célját és nem hoz döntéseket az erőforrások elosztásáról, csupán közvetítő szerepet tölt be.
Ez a felépítés megfordítja a klasszikus operációs rendszerek működési logikáját: ahelyett, hogy a mag biztosítana keretrendszert a folyamatoknak, a felhasználói módban futó, külső komponensek maguk határozzák meg együttműködésük szabályait és protokolljait. A nanokernelben a hagyományos értelemben vett rendszerhívások helyét könyvtári rétegek és közvetlen szolgáltatásközi kommunikáció veszi át, így a rendszer integritását nem egy központi algoritmus, hanem az egyes elemek saját izolációs szabályai garantálják. Mivel a mag szinte alig tárol változó belső állapotot, a kódja statikusan rendkívül stabil és formális matematikai módszerekkel is igazolható. Ez a „high-assurance” jelleg teszi a nanokernelt a legbiztonságosabb választássá az olyan speciális architektúrák számára, ahol a megbízhatóság minden más szempontot megelőz.
Történeti háttér és példák
A nanokernel fogalma a mikrokerneles kutatások hajnalán, a ’80-as években született meg. A „nano” vagy „piko” jelzőkkel azokat a kísérleti rendszereket illették, amelyek mérete és funkcionalitása még a mikrokernelt is alulmúlta. Az egyik úttörő az IBM mainframe-eken futó KeyKOS volt: a mindössze 20 ezer sornyi kódból álló mag alig 100 kilobájt memóriát igényelt. Különlegessége a képességalapú (capability-based) védelem és az állapotmentes felépítés volt, ahol az operatív memória és a háttértár egységes egészet alkotott. A KeyKOS utódai (EROS, Coyotos) bebizonyították: a minimális kódméret nemcsak stabilitást, hanem formálisan is igazolható, extrém biztonsági szintet garantál.
A nanokernel filozófia a mainstream világban is felbukkant, például az Apple klasszikus Mac OS 8 és 9 rendszereiben. Itt egy apró nanokernel réteg felelt a PowerPC hardver közvetlen kezeléséért, miközben a régi, 68k-alapú rendszer egy emulált környezetben futott felette. Bár a későbbi verziók már üzenetküldéssel és védett memóriával bővültek – így inkább hasonlítottak egy mikrokernelre –, az Apple példája jól mutatta, hogyan használható egy vékony szoftverréteg a hardverarchitektúrák közötti átmenet biztosítására.
A koncepció a modern kísérleti projektekben is jelen van, mint például a Java nyelven írt JNode. Ebben a rendszerben egy assemblerben írt, parányi nanokernel végzi el a kritikus x86-os alapbeállításokat, majd azonnal átadja a vezérlést a Java virtuális gépnek. Innentől kezdve minden – a hálózattól a fájlrendszerig – a felhasználói térben, Java-ban valósul meg. Ez a megoldás remekül szemlélteti, hogy a nanokernel csupán egy vékony absztrakciós hidat képez a nyers hardver és a magas szintű programozási környezetek között.
Exokernel: absztrakciók nélküli kernel
Alapötlet és működés
Az exokernel architektúra radikálisan más irányból közelíti meg a kernel kérdését, mint a mikro- vagy nanokernel. Az exokernel alapeszméje az, hogy az operációs rendszer magja ne nyújtson magas szintű absztrakciókat a hardver erőforrásaihoz. Míg egy hagyományos kernel elrejti a nyers hardvert az alkalmazások elől – fájlrendszereket, virtuális memória absztrakciót, folyamatokat, socketeket kínál az egyszerű használathoz –, addig az exokernel ezzel szemben a lehető legkevesebbet “leplez el” a hardverből.
Az exokernel a nevében az “exo-” (külső) előtagot viseli, utalva arra, hogy a magas szintű operációs rendszer funkciók kvázi a kernel külső rétegeiben, user-space-ben valósulnak meg, nem magában a kernelben.
Egy exokernel típusú rendszermag mindössze két fő feladatot lát el: védelmet és multiplexelést. Vagyis az exokernel gondoskodik arról, hogy a különböző (egymásban nem megbízó) programok biztonságosan megoszthassák a hardver erőforrásait – ne férjenek hozzá egymás memóriájához, ne lépjék túl a számukra kiosztott erőforrás-kontingenseket –, illetve hogy párhuzamosan futhassanak, megosztva a CPU időt, perifériákat. Amit az exokernel nem vállal magára, az a magas szintű absztrakciók biztosítása: nem alakítja át a hardvert egységes, kényelmesen használható erőforrás-modellekké.
Például egy hagyományos kernelben, ha egy alkalmazás fájlt akar olvasni, akkor a kernel ad egy fájlrendszer absztrakciót (fájl-descriptor, read/write hívások stb.), a háttérben pedig kezelheti a lemezmeghajtót, cache-li az adatokat, és így tovább. Ezzel szemben egy exokernel nem biztosít feltétlenül fájlrendszer API-t – helyette megengedi, hogy az alkalmazás (vagy pontosabban egy könyvtári operációs rendszer, lásd később) közvetlenül kérjen blokkhozzáférést a lemezhez.
A kernel csak annyit tesz, hogy ellenőrzi: a kért lemezblokk nincs-e már valaki más által lefoglalva, és hogy az adott folyamat jogosult-e hozzáférni – ha igen, engedélyezi, hogy a folyamat közvetlenül olvassa vagy írja a blokkot. Hasonlóképpen, memóriakezelésnél az exokernel nem kényszerít egységes virtuális címtér modellt a folyamatokra; inkább megengedi, hogy egy alkalmazás konkrét fizikai memória kereteket kérjen és kezeljen, amennyiben ezt biztonságosan meg tudja tenni. Az exokernel tehát egyfajta minimalista erőforrás-felügyelő: ő rendelkezik az erőforrások kiosztásáról és védi őket, de nem mondja meg, hogyan használja azokat a program.
Ahhoz, hogy a rendszer használható maradjon, az exokernel modellel együtt jár a library OS fogalma. A valódi szoftverek írói nyilván nem szeretnének minden alkalommal alacsony szinten, például konkrét lemezblokkokkal bíbelődni vagy saját memóriamenedzsert írni. Ezért az exokernel fölött, a felhasználói térben futnak azok a könyvtárak, amelyek a megszokott OS absztrakciókat megvalósítják. Ezek a library OS-ek lényegében a hagyományos kernel szolgáltatásait nyújtják, de nem a kernelben, hanem mint közönséges (bár nyilván speciális jogosultságokkal rendelkező) programkönyvtárak. Több különböző library OS is létezhet egy exokernel fölött – akár alkalmazásonként eltérő is lehet.
Például egy exokernel rendszerben futtatható egyszerre egy POSIX-kompatibilis library OS (ami a Linux/UNIX rendszerhívásokat valósítja meg user-space-ben), és mellette egy másik folyamat használhat egy teljesen egyedi library OS-t, mondjuk valamilyen valós idejű feladatokra optimalizáltat. Mindketten ugyanazt az exokernel magot hívják meg erőforrásokért, de máshogy interpretálják azokat. Ez az exokernel legnagyobb előnye: szabadságot ad a magas szintű működés testreszabására. Az alkalmazás fejlesztője – vagy tipikusan az általa használt library OS fejlesztője – eldöntheti, milyen ütemezőt, memóriakezelőt, fájlrendszert akar használni, ahelyett hogy a kernel által előre beépítettekre hagyatkozna.
Ha egy speciális célú programnak speciális igénye van, megírhatja a saját “kis operációs rendszerét” az exokernel tetején, anélkül hogy saját kernelt kellene írnia. Ez a fajta modularitás és testreszabhatóság az end-to-end (végponttól végpontig) elv alkalmazása az operációs rendszerekre: ami absztrakciót nem muszáj a kernelben megoldani, azt oldja meg a felhasználói program, így elkerüljük, hogy a kernel univerzális, de nem tökéletes megoldásai mindenkit és mindent korlátozzanak.
Történeti háttér
Az exokernel koncepciója a ’90-es évek közepén, az MIT PDOS kutatócsoportjánál született meg. Dawson R. Engler és kollégái 1995-ben mutatták be az első prototípust, amely az Aegis exokernel magból és az ExOS könyvtári operációs rendszerből (library OS) állt.
A kísérleti rendszer bebizonyította, hogy a modell életképes: a speciális célú szoftverek jelentős teljesítménynövekedést értek el, miközben az ExOS réteg révén a hagyományos UNIX programok is futtathatók maradtak. Későbbi fejlesztések, mint a Xok kernel és a Cheetah webszerver, igazolták, hogy az alacsony szintű erőforrás-kezelés – például az IP-csomagok közvetlen lemezkezelése – drasztikusan gyorsíthatja a hálózati kiszolgálást, mivel a kernel csak a védelmet garantálja, de a folyamatba nem szól bele.
Bár az ötlet forradalmi volt, az exokernel gyakorlati elterjedése elmaradt. A fejlesztők számára komoly kihívást jelentett a megszokott absztrakciók hiánya, egy széles körben használható operációs rendszerhez pedig rengeteg különböző, párhuzamosan karbantartott library OS-re lett volna szükség, ami kezelhetetlen komplexitást szült.
Az exokernel szellemisége azonban ma is él. A unikernel technológia, ahol az alkalmazás egy saját mini OS-szel egyetlen egységként fut a hypervisoron, közvetlen ideológiai utódnak tekinthető. Hasonló elveket vall a Microsoft Drawbridge projektje is, amely könyvtári szintű izolációt használ. Ezek a kezdeményezések mind azt az exokernel-alapvetést viszik tovább, hogy az operációs rendszer ne egy merev korlát, hanem az alkalmazás igényeihez alakítható, moduláris platform legyen.
Multikernel: operációs rendszer mint elosztott rendszer
Alapötlet és működés
A multikernel architektúra a 2000-es évek végén megjelent új megközelítés, amelyet elsősorban a modern hardverek – a sokmagos processzorok és a heterogén számítási platformok – kihívásai inspiráltak. A multikernel alapfelvetése az, hogy egy többmagos gépet olyan módon kezeljünk, mintha egy elosztott rendszer lenne, nem pedig egy hagyományos, közös memórián osztozó számítógép. Hagyományos operációs rendszerekben a kernel a processzor magjait általában közös adatszerkezetekkel, zárolásokkal (lock) szinkronizálja – hiszen közös memóriát feltételezünk, így a kernel globális változókat, listákat használ a folyamatok nyilvántartására, a memória-allokációra stb.
Amikor azonban a magok száma drasztikusan megnő, vagy a rendszerben különböző típusú magok (például CPU és kisegítő GPU vagy DSP magok) vannak, a közös memórián osztozó kernelmodell skálázhatósági és tervezési problémákba ütközik. A magok közti folyamatos szinkronizáció (cache-koherencia fenntartása, globális lockok kezelése) komoly teljesítménybeli korlátozó tényezővé válhat, és a heterogén magok esetén nehéz egységesen kezelni a különböző képességű processzorokat.
A multikernel erre a problémára azzal válaszol, hogy minden processzormagon saját kernelpéldányt futtatunk, amelyek laza kapcsolatban állnak egymással. Úgy is mondhatjuk, hogy ha van egy 8 magos gépünk, akkor ahelyett hogy egy operációs rendszer futna 8 szálon, inkább nyolc kicsi operációs rendszer fut, egy-egy magon. Ezek a kernelpéldányok nem osztanak meg közvetlenül belső adatszerkezeteket – tehát nincs közös, globális process-lista például.
Ehelyett, ha információt kell cserélniük (például egy folyamat egyik magról átkerül egy másik magra), akkor üzenetküldéssel kommunikálnak egymással, mintha a hálózatba kapcsolt külön számítógépek lennének. A multikernel architektúra tehát explicit módon kezeli a kommunikációt a magok között: ahelyett, hogy a hardver cache-koherenciára és a megosztott memóriára “bíznánk” a szinkront (ami bonyolult és rejtett költségekkel jár), a kernel maga küld üzenetet a többi kernelnek, ha valamilyen változást (például egy erőforrás állapotváltozását) közölni akarja.
Emellett a multikernel elv másik sarokpontja az, hogy a rendszer állapotát replikálja a magok között, ahelyett hogy megosztaná. Vagyis például minden magon lehet saját ütemezője a futó feladatokkal, saját memóriakezelője a helyi memóriapartícióval, saját eszközkezelő komponense, és így tovább. Ha szükséges, ezek az állapotok szinkronban tarthatók üzenetek révén (gyakorlatilag egyfajta cache-koherenciát valósítva magasabb szinten), de nincs egyetlen központi adatszerkezet, amin osztozniuk kellene. Ez a “minden mag a saját uradalma” felépítés hasonlít egy klaszter vagy felhő architektúrára – csak itt a klaszter csomópontjai nem külön gépek, hanem CPU magok egy chipen belül.
Barrelfish: a multikernel úttörője
A multikernel ötlet legismertebb megvalósítása a Barrelfish operációs rendszer, amelyet az ETH Zürich egyetem és a Microsoft Research cambridge-i laborja közösen fejlesztett kutatási projektként 2007–2010 között. A Barrelfish egy nyílt forrású kísérleti OS, melynek célja pontosan az volt, hogy kipróbálja a multikernel koncepciót a gyakorlatban. A fejlesztők motivációját két fő trend adta: egyrészt a processzormagok számának rohamos növekedése (multi- és many-core processzorok megjelenése), másrészt a számítógépes hardverek egyre növekvő sokfélesége (például heterogén architektúrák, külön specializált magok egy rendszerben). Úgy látták, hogy 5–10 éven belül, a 2010-es évek folyamán a hagyományos operációs rendszerek nehezen fogják tudni hatékonyan kihasználni az ilyen komplex hardvereket – új paradigmára van szükség.
A Barrelfish a multikernel modell minden magon futtat egy apró kernelt (ezt nevezik CPU drivernek a Barrelfish terminológiájában). Ezek a kernelpéldányok nem osztanak meg memóriát egymással még akkor sem, ha egyébként a hardver támogatja a cache-koherenciát; kizárólag üzenetküldéssel (szálak közti üzenetek formájában) kommunikálnak, például ha egy alkalmazás több magot is használ. A magasabb szintű OS-szolgáltatások (fájlrendszer, hálózat, stb.) pedig egyfajta elosztott rendszerként vannak megírva a magok fölött: minden szolgáltatás komponensei külön folyamatként futnak, szükség esetén együttműködve (üzenetekkel) a többi magon levő társaikkal.
A végeredmény az, hogy az egész gép úgy viselkedik, mintha egy kis hálózat lenne a magok között, amelyek csomópontokként működnek egy elosztott operációs rendszerben. Az átlagos alkalmazás ezt persze nem érzékeli közvetlenül – a Barrelfish esetében is biztosítanak egy C nyelvű API-t folyamatok létrehozására, kommunikációra stb., csak a háttérben nem egy centralizált kernel hívásai történnek, hanem egy üzenet-orientált működés zajlik. A Barrelfish készítőinek koncepciója az volt, hogy e megközelítés révén hatékonyabban tudják skálázni az operációs rendszert sok magra: a rendszer teljesítménye bizonyos feladatoknál jobban nőtt a magok számával, mint a hagyományos Linux vagy Windows esetében, mert a Barrelfish kiiktatott sok rejtett költséget (például globális zárak okozta várakozást) azáltal, hogy explicitté tette a magok közti kommunikációt.
Ráadásul a multikernel struktúra hardver-semlegesebb: mivel nincs kódba égetve, hogy “ez egy x86-os PC 8 maggal”, a Barrelfish könnyebben portolható volt más architektúrákra, beleértve a heterogén rendszereket is. A tervezési alapelvek között deklarálták azt is, hogy a rendszer szerkezete legyen hardverfüggetlen, és kezelje természetes módon a replikált állapotot a megosztott helyett. Ez lehetővé teszi, hogy a Barrelfish-sel olyan platformokat is ki lehessen használni, ahol külön CPU és GPU magok vannak egyenrangúként jelen, vagy akár nem cache-koherens multiprocesszor rendszereket is.
Eredmények és hatás
A Barrelfish projekt kutatói 2009-ben publikálták mérföldkőnek számító tanulmányukat, amelyben bizonyították a multikernel-megközelítés életképességét. A mérések szerint a Barrelfish teljesítménye nemcsak felvette a versenyt a hagyományos, közös memóriát használó operációs rendszerekkel, hanem bizonyos terheléseknél – a globális zárolások kiiktatásának köszönhetően – jobban is skálázódott a magok számával. Fontos eredmény, hogy ez a haszon már a korabeli, 8–16 magos processzorokon is megmutatkozott, hatékonyabb terheléselosztást és jobb gyorsítótár-kezelést eredményezve.
A projekt rámutatott, hogy a szoftveresen megoldott, explicit üzenetküldés révén az operációs rendszer képes alkalmazkodni a változó hardvertopológiákhoz és a komplex cache-hierarchiákhoz. Bár a Barrelfish kutatási prototípus maradt (utolsó kiadása 2020-as), alapelvei beszivárogtak a mainstream rendszerekbe is. A Linux kernel fejlesztése során például folyamatosan törekednek a globális zárolások minimalizálására és az alrendszerek NUMA-csomópontonkénti elkülönítésére, ami a multikernel-filozófia egyik gyakorlati alkalmazása.
Összességében a multikernel jelentősége abban rejlik, hogy a skálázhatóságot tette a tervezés alapjává, átírva az operációs rendszerek hagyományos alaprajzát. A heterogén rendszerek (például az ARM big.LITTLE) és a specializált SoC-k korában az üzenetközpontú szinkronizáció és a hardvertopológiához igazodó ütemezés egyre felértékelődik. A Barrelfish bebizonyította, hogy a kernelre nem feltétlenül központi irányítóként, hanem a magok közötti együttműködést koordináló, rugalmas rétegként is tekinthetünk.
Unikernel: az alkalmazás saját, lezárt minivilága
Alapötlet és működés
Az unikernel az operációs rendszer és az alkalmazás közti határvonalat gyakorlatilag eltünteti: a cél nem egy általános célú, sokféle programot kiszolgáló OS, hanem egyetlen feladatra “összerakott” rendszerkép, amelyben az alkalmazás és a számára szükséges operációs rendszer-szolgáltatások egyetlen bináris egységgé állnak össze. A klasszikus definíció szerint az unikernel egy specializált, egy címtérben futó gépkép, amelyet úgy kapunk meg, hogy az alkalmazást statikusan összelinkeljük egy könyvtári operációs rendszer (library OS) komponenseivel.
A végeredmény nem egy Linux-szerű vendég OS, hanem egy olyan, kifejezetten az adott alkalmazásra szabott image, amely jellemzően közvetlenül egy hypervisor vendégeként fut (például Xen vagy KVM alatt), külön “teljes” operációs rendszer réteg nélkül.
A működés kulcsa a moduláris felépítés. Unikernel környezetben az olyan megszokott alrendszerek, mint a hálózati stack, a memóriakezelés, a futásidejű ütemezés, vagy akár egy minimalista fájlrendszer-támogatás, tipikusan linkelhető könyvtárkomponensekként léteznek. A buildfolyamat (compile és linkelés) során csak azok a darabok kerülnek be a végső image-be, amelyekre az alkalmazásnak ténylegesen szüksége van; ami nem kell, egyszerűen nincs jelen. Ebből adódik az unikernel egyik legszembetűnőbb sajátossága: sok implementációban nincs hagyományos kernel–user tér szétválasztás, mert az egész rendszer egyetlen címtérben működik, ezért a klasszikus rendszerhívás-útvonal és a privilege váltások jelentős része eleve értelmét veszti, és a “kernel-szolgáltatás” gyakran sima függvényhívássá egyszerűsödik.
A „lezártság” is központi elem: sok unikernel esetén a futó image nem egy általános célú rendszer, amit utólag bővítesz csomagokkal, finomhangolsz konfigurációval, majd működés közben foltozol. Inkább egy készre épített, appliance-jellegű egységként viselkedik. Ha változtatni kell rajta, nem a futó példányt alakítod át, hanem új image-et állítasz elő, és azt cseréled le. Ez a szemlélet kifejezetten passzol a felhős üzemeltetéshez, az infrastruktúra mint kód megközelítéshez és az „immutable” telepítésekhez, ahol a frissítés eleve gyakran új példány indítását és a régiek lecserélését jelenti.
Történeti háttér és példák
Az unikernel a library OS koncepciójából és az operációs rendszerek komponensekre bontásának kutatásaiból fejlődött ki. Modern reneszánsza a 2010-es évek elején kezdődött, amikor a virtualizáció elterjedése felvetette: ha a hardver csupán egy hypervisor-absztrakció, miért cipeljünk minden szolgáltatáshoz egy teljes, univerzális operációs rendszert? Ezt a szemléletet a MirageOS tette ismertté, amely felhőre optimalizált, egycélú rendszerképként definiálta az unikernelt.
A MirageOS a „nyelv + library OS” elvét követve moduláris komponensekből épít fel kisméretű rendszereket. Ezzel párhuzamosan jelentek meg a pragmatikusabb irányok, mint az OSv, amelyet kifejezetten virtuális gépekre és cloud-terhelésekre terveztek. Más projektek, például a Rumprun, a NetBSD ökoszisztémájából emelnek át kiforrott kernelkomponenseket (drivereket, alrendszereket), így elkerülve az alapoktól való újraírást.
A 2010-es évek második felére a cél a szélesebb körű használhatóság lett. Erre kiváló példa az Unikraft, amely egyfajta moduláris eszköztárként teszi lehetővé az OS-elemek válogatását. A futtatási oldalt olyan technológiák segítik, mint a Solo5, amely sandboxolt környezetben biztosítja az unikernel-típusú feladatok végrehajtását különféle hypervisorok felett.
Felhasznált források
- Bomberger et al. (1992) – The KeyKOS Nanokernel Architecture. USENIX Workshop on Micro-Kernels and Other Kernel Architectures, 1992. (A KeyKOS operációs rendszer minimalista, képesség-alapú nanokerneljének bemutatása, eredeti cikk)
- Engler, Kaashoek & O’Toole (1995) – Exokernel: An Operating System Architecture for Application-Level Resource Management. Proc. 15th ACM SOSP, 1995. (Az exokernel koncepció első publikációja, MIT PDOS – Aegis exokernel és ExOS library OS)
- Microsoft Research, Cambridge, Systems Group, ETH Zurich (2009) – The Multikernel: A new OS architecture for scalable multicore systems. Proc. 22nd ACM SOSP, 2009. (A Barrelfish operációs rendszer és a multikernel modell részletes ismertetése, teljesítményértékeléssel)
- Barrelfish Project (2009–2020) – Barrelfish OS Documentation (Hivatkozás). (A Barrelfish kutatási operációs rendszer honlapja és dokumentációja, információk a multikernel architektúra gyakorlati megvalósításáról)
- Anil Madhavapeddy: Unikernels: Library Operating Systems for the Cloud (MirageOS-alapú megközelítés, felhős motivációk és előnyök). (Hivatkozás)
