Array ( [0] => 14687858 [id] => 14687858 [1] => cswiki [site] => cswiki [2] => Mikrojádro [uri] => Mikrojádro [3] => [img] => [4] => [day_avg] => [5] => [day_diff] => [6] => [day_last] => [7] => [day_prev_last] => [8] => [oai] => [9] => [is_good] => [10] => [object_type] => [11] => 0 [has_content] => 0 [12] => [oai_cs_optimisticky] => ) Array ( [0] => {{Možná hledáte|[[Mikronukleus]] – jedno z [[Buněčné jádro|buněčných jader]] při [[Jaderný dualismus|jaderném dualismu]]}} [1] => {{upravit}} [2] => [[Soubor:Kernel-microkernel.svg|náhled|Mikrojádro]] [3] => '''Mikrojádro''' je v [[Informatika|informatice]] typ [[Jádro operačního systému|jádra]] [[operační systém|operačního systému]], které je velmi malé a obsahuje jen nejzákladnější funkce (typicky [[Správa paměti|správu paměti]] a podporu pro [[plánování procesů]] a [[Meziprocesová komunikace|meziprocesové komunikace]]), čímž se minimalizuje objem běžícího kódu v [[Privilegovaný režim|privilegovaném režimu]]. Ostatní potřebné části jádra jsou řešeny v uživatelském prostoru jako běžné [[Proces (informatika)|procesy]] (resp. [[Démon (software)|démoni]], u mikrojader se označují ''servery''), například správa [[souborový systém|souborového systému]], [[Ovladač zařízení|ovladače zařízení]], podpora [[Protokol (informatika)|protokolů]] pro [[Počítačová síť|počítačové sítě]] a další. Mezi zástupce systémů s mikrojádrem patří [[operační systém]] [[MINIX 3]], [[GNU Hurd]] (s mikrojádrem [[GNU Mach]]), [[L4Linux]] (s mikrojádrem [[L4 (jádro)|L4]]-Fiasco.OC){{Citace elektronické monografie [4] => | vydavatel = TU Dresden [5] => | datum_přístupu = 2015-06-17 [6] => | url = http://l4linux.org/ [7] => | jazyk = anglicky [8] => }}, [[PikeOS]], [[QNX]] a [[Symbian OS]]. Opakem mikrojádra je [[monolitické jádro]], kompromisem pak [[hybridní jádro]]. [9] => [10] => == Charakteristika == [11] => Mikrojádro je novější odlišný návrh, který se staví do protikladu k [[Monolitické jádro|monolitickému jádru]], u kterých byl kvůli velikosti obtížný vývoj a údržba.[http://www.oreilly.com/openbook/opensources/book/appa.html – Open Sources: Voices from the Open Source Revolution (Tanenbaum-Torvalds Debate)] Návrh mikrojádra proto odpovídá teorii [[Strukturované programování|strukturovaného programování]].[[Edsger Dijkstra]] označil GOTO za škodlivý příkaz v roce 1969 a v roce 1972 vydal pojednání o [[Strukturované programování|strukturovaném programování]] Rozdělení na více samostatných logických celků umožňuje získat vysoké hodnocení bezpečnosti [12] => {{cite conference [13] => | first = Gerwin [14] => | last = Klein [15] => | coauthors = Elphinstone, Kevin; Heiser, Gernot; Andronick, June; Cock, David; Derrin, Philip; Elkaduwe, Dhammika; Engelhardt, Kai; Kolanski, Rafal; Norrish, Michael; Sewell, Thomas; Tuch, Harvey; Winwood, Simon [16] => | title = seL4: Formal verification of an OS kernel [17] => | booktitle = 22nd ACM Symposium on Operating System Principles [18] => | pages = [19] => | month = October [20] => | year = 2009 [21] => | location = Big Sky, MT, USA [22] => | doi = [23] => | url = http://www.sigops.org/sosp/sosp09/papers/klein-sosp09.pdf [24] => }} a zajistit vysokou spolehlivost.[http://www.cs.vu.nl/~ast/reliable-os/ – Tanenbaum-Torvalds Debate: Part II] [25] => [26] => V některých případech je za výhodu mikrojádra označována schopnost se udržet v chodu i poté, co dojde v některém z podsystémů k závažné chybě, protože příslušný server může být restartován. Velkým problémem je však v takovém případě ztráta původního stavu (například navázaná síťová spojení, obsahy bufferů, cache), kterou lze řešit jen na úkor komplexity obsluhy serverů a jejich interních mechanismů. Tato vlastnost také může vést ke kontraproduktivnímu postoji, že pro mikrojádra není nutné vytvářet 100% spolehlivé ovladače. [27] => [28] => Nespornou výhodou mikrojádra je schopnost jednoduše pozastavit jednotlivé servery a případně odpojit od napájení i jimi ovládané zařízení, což může vést k úsporám elektrické energie (např. [[Symbian OS]]) a což nelze v monolitickém jádře tak snadno zařídit. [29] => [30] => === Vliv na výkon === [31] => Nevýhodou mikrojádra je, že při požadavku na službu jádra je nutné projít několika [[Změna kontextu|změnami kontextu]] mezi žádajícím procesem, mikrojádrem a obsluhujícími servery (na rozdíl od monolitického jádra, kde dojde při [[systémové volání|systémovém volání]] jádra jen ke dvěma změnám mezi kernel a user space). Dalším problémem je mechanismus [[Meziprocesová komunikace|meziprocesové komunikace]], který vede k velkým ztrátám na výkonu (a lavinovitým změnám kontextu). V tomto ohledu lze však pečlivým návrhem dosáhnout značných vylepšení.{{cite conference [32] => | first = Jochen [33] => | last = Liedtke [34] => | authorlink = Jochen Liedtke [35] => | coauthors = [36] => | title = Improving IPC by kernel design [37] => | booktitle = 14th ACM Symposium on Operating System Principles [38] => | pages = 175–88 [39] => | publisher = [40] => | month = December [41] => | year = 1993 [42] => | location = Asheville, NC, USA [43] => | url = http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.40.1293&rep=rep1&type=pdf [44] => | accessdate = [45] => | id = [46] => }} Další nevýhodou je vlastní návrh mikrojádra, který vyžaduje existenci více či méně oddělených datových struktur, zatímco v monolitickém jádře jsou všechna data přístupná přímo, což umožňuje dosahovat vyššího výkonu, což vedlo u některých systémů k příklonu k hybridnímu jádru (např. [[Windows NT]], [[Windows CE]]). [47] => [48] => Mnoha ohledům výhod a nevýhod se věnovaly debaty mezi [[Linus Torvalds|Linusem Torvaldsem]] (tvůrce monolitického [[Linux (jádro)|jádra Linuxu]]) a [[Andrew S. Tanenbaum|Andrewem S. Tanenbaumem]] (tvůrce mikrojádra [[MINIX]]u). [49] => [50] => == Mikrojádro a Unix == [51] => Unixová filozofie původně představovala malé jádro, které je považováno za dokonale bezchybné. První jádra operačních systémů, stejně jako Unixu byla původně malá. S postupným vývojem hardware, stejně jako s rostoucím počtem podporovaných služeb tato jádro nabývala na velikosti. Postupně tak docházelo ke vzniku jader, která mají i milióny řádek zdrojového kódu. I když jsou [[UN*X|unixové systémy]] tradičně spojeny s monolitickými jádry, může být i unixové jádro implementováno jako mikrojádro. Příkladem je operační systém [[MINIX 3]]Towards a True Microkernel Operating System, viz http://www.minix3.org/theses/herder-true-microkernel.pdf a jádro [[GNU Mach]]. [52] => [53] => Nevýhodou rozsáhlých monolitických jader je, že u nich nelze dosáhnout původního předpokladu unixové filozofie – totiž toho, že takové jádro bude (z praktického hlediska) prosté chyb a tudíž bezchybně fungující. To je jeden z důvodů, že jen málokterý operační systém dnes neobsahuje mikrojádrové prvky včetně např. Microsoft Windows či macOS. [54] => [55] => == Meziprocesová komunikace == [56] => {{Viz též|Meziprocesová komunikace}} [57] => [58] => Meziprocesová komunikace umožňuje odděleným procesům komunikovat navzájem, obvykle [[zasíláním zpráv]]. Pro implementaci se často používá [[sdílená paměť]]. Meziprocesová komunikace je pro mikrojádra kritickým místem, který má zásadní vliv na jejich výkon (viz výše). [59] => [60] => IPC může být synchronní nebo asynchronní. Asynchronní IPC je analogická se síťovou komunikací: odesilatel odešle zprávu a pokračuje v provádění činnosti. Příjemce dotazováním zkontroluje dostupnost zprávy při pokusu ji obdržet nebo je na přijetí zprávy upozorněn přes jiný mechanismus oznamování. Asynchronní IPC vyžaduje, aby jádro udržovalo vyrovnávací paměti a fronty zpráv, a zabývá se přetečením vyrovnávací paměti; ale také vyžaduje dvojité kopírování zpráv (odesílatel jádru a jádro příjemci). V synchronní IPC první strana (odesilatel nebo příjemce) blokuje, než druhá strana je připravena k realizaci IPC. Nevyžaduje vyrovnávací nebo vícenásobné kopie, ale implicitní setkání může být pro programování ošidné. Většina programátorů proto raději používá asynchronní a synchronní příjem zároveň. [61] => [62] => První generace mikrojader obvykle podporovala synchronní i asynchronní IPC, ale neměla tak vysoký výkon. [[Jochen Liedtke]] navrhl design a implementaci IPC mechanizmů jako důvod k vyřešení špatného výkonu. Jeho mikrojádra rodiny [[L4 (jádro)|L4]], díky nimž se stal průkopníkem v technice, vedla k [[řádová velikost|řádovému]] snížení režie IPC. Mezi ně patří systém IPC volání, který podporuje odesílací a přijímací operace, takže všechny IPC jsou synchronní a předávají mnoho dat skrze [[Registr procesoru|registry procesoru]]. Dále Liedtke představil koncept ''přímého procesového přepínače'', kde se v průběhu vykonávání IPC provádí neúplná [[změna kontextu]] přímo od odesílatele k příjemci. Stejně jako v [[L4 (jádro)|L4]] je část nebo celá zpráva předávána jen uvnitř registrů, převod části zprávy v registrech se děje bez jakéhokoliv kopírování. Kromě toho se vyhneme režii vyvolávací paměti, což je zvláště výhodné v případě, kdy se IPC používá ve [[Vzdálené volání procedur|vzdáleném volání procedur]] (RPC), tedy klientem iniciované volání serveru. Další optimalizace, tzv. ''líné plánování'', zabraňuje křížení plánovací fronty v IPC tím, že uvolní vlákna, která blokují IPC v připravené frontě. Jakmile je plánovač použit, přenese taková vlákna do čekající fronty. V mnoha případech se vlákno odblokuje před dalším vyvoláním plánovačem, tato metoda nám ušetří práci. Podobné metody byly adoptovány v systémech [[QNX]] a [[MINIX]]. [63] => [64] => V systémech klient-server je většina komunikace v podstatě synchronní, a to i v případě použití asynchronních základů. Typický provoz je takový, že klient vyvolá server a pak čeká na odpověď. Asynchronní IPC může být prováděna použitím pomocníka vláken ({{Vjazyce2|en|''helper threads''}}). Avšak díky verzi L4 implementované v komerčních produktech se zjistilo, že je nezbytné pro lepší komunikaci přidání asynchronního oznamování. Tento [[Signál (informatika)|signál]] nepřenáší data, a proto nevyžaduje vyrovnávací paměti jádra. [65] => [66] => Jak synchronní IPC blokuje jednu stranu, než je druhá strana připravena, tak by jeho neomezené použití mohlo vést k zablokování ([[deadlock]]). Mimoto může klient snadno způsobit [[Denial of Service|odmítnutí služby]] na serveru tak, že odesílá požadavky a nikdy se nepokusí o získání odpovědi. Proto se u synchronního IPC často využívá [[timeout]]ů, které omezují dobu blokování IPC. V praxi je výběr rozumné hodnoty časového limitu obtížný a systémy téměř nevyhnutelně používají nekonečné časové limity pro klienty a nulové časové limity pro servery. V důsledku toho je, že trend nesměřuje k poskytování libovolného časového limitu, ale pouze příznaku, který ukazuje, že IPC selhalo. Tento přístup účinně nabízí výběr ze dvou timeoutových hodnot nuly a nekonečna. Poslední verze L4 a Minixu šly touto cestou (starší verze L4 používá časové limity, stejně jako QNX). [67] => [68] => == Servery == [69] => Základní sada serverů pro univerzální mikrojádro zahrnuje servery souborového systému, servery ovladačů zařízení, síťové servery, servery displeje a uživatelské rozhraní serveru zařízení. Tato sada serverů (převzato od [[QNX]]) poskytuje zhruba soubor služeb, jako [[monolitické jádro]] u [[UN*X|unixových systémů]]. Potřebné servery jsou spuštěny systémem a poskytují služby, jako je [[souborový systém]], síť a přístup k zařízením pro běžné aplikační programy. Servery běží v prostředí běžných uživatelských aplikací. Vývoj serverů je spíše podobný vývoji běžných aplikací, než programování na úrovni jádra systému. Chybové stavy lze korigovat zastavením a restartováním serveru, avšak tím se ztrácí informace o původním stavu komunikace či výpočtu, a proto tento přístup vyžaduje, aby se aplikace uměla vyrovnat s neúspěchem při volání služby poskytované serverem. Příkladem může být server zodpovědný za [[TCP/IP]] stack (síťový subsystém): pokud je tento server restartován, aplikace zaznamená výpadek spojení, což je však v prostředí sítí běžný jev. U jiných služeb se však běžně neočekává, že jejich volání selže, a proto tento přístup může vyžadovat změny v kódu aplikace. [70] => [71] => Proto, aby všechny servery byly restartovatelné, se některá mikrojádra soustředila na přidávání různých [[Databáze|databázových]] technik, jako jsou [[databázová transakce|databázové transakce]], [[replikace]] a [[checkpointing]]. V případě, že má být zachován základní stav, se restartuje jen jeden server. Příkladem je [[ChorusOS]], který byl zaměřen na zajištění vysoké dostupnosti aplikací [[telekomunikace|telekomunikačního]] světa. Chorus zahrnoval vlastnosti, které dovolují „nesprávně napsané“ servery kdykoliv restartovat. Klienti používající tyto servery jsou pozastaveni, zatímco se server vrací zpět do původního stavu. [72] => [73] => == Ovladače zařízení == [74] => [[Ovladač zařízení]] využívá často přímý přístup do paměti nebo programování [[DMA]] přenosů, a proto potřebuje mít možnost zapisovat na libovolné místo [[Operační paměť|operační paměti]] včetně datových struktur jádra. Takové ovladače proto musí být z hlediska zbytku jádra (či systému) důvěryhodné. Proto však nutně nemusí být ovladač součástí jádra. [75] => [76] => Uživatelský režim ovladačů ve skutečnosti přebírá mikrojádro. [[Michigan Terminal System]] (MTS) byl již v roce [[1967]] prvním systémem, který podporoval ovladače realizované v uživatelském prostoru (včetně podpory souborového systému). Historicky byly ovladače menším problémem, protože počet zařízení byl malý a věřilo se, že se to nezmění. Ovladač v jádře znamenal jednodušší návrh a eliminaci problémům s výkonem. To vedlo k tradiční implementaci ovladačů v jádře systému ve stylu původních [[UN*X|unixových systémů]] jako je [[Linux]], ale i pro systémy [[Microsoft Windows]]. S postupem času se počet různých typů periferií zvětšoval a tím i množství kódu nutného pro ovladače, takže v současných systémech tvoří ovladače většinu [[Zdrojový kód|zdrojového kódu]]. [77] => [78] => == Nutné komponenty a minimalita == [79] => Mikrojádro musí minimálně, mimo libovolných služeb operačního systému, poskytnout tyto mechanismy: [80] => * Mechanismy pro správu [[adresní prostor|adresového prostoru]] (potřebné pro ochranu paměti) [81] => * Mechanismy pro alokaci [[Centrální procesorová jednotka|CPU]] ([[vlákno (program)|vlákna]], [[plánovač procesů|plánovače procesů]]) [82] => * Mechanismy pro [[meziprocesová komunikace|meziprocesorovou komunikaci]] [83] => Průkopníky ve využití minimálního designu byly operační systémy Nucleus (zakladatel Brinch Hansen) a VM (od IBM). [84] => [85] => Jochen Liedtke stanovil tzv. ''minimální princip'', který vypadá takto: [86] =>
[87] => Koncept je tolerován uvnitř mikrojádra, pouze když přesun vně jádro, tj. povolení implementací, by zabránil implementaci požadované systémové funkcionality. [88] => {{cite conference [89] => | first = Jochen [90] => | last = Liedtke [91] => | authorlink = Jochen Liedtke [92] => | title = On µ-Kernel Construction [93] => | booktitle = 15th ACM symposium on Operating Systems Principles [94] => | pages = 237–250 [95] => | year = 1995 [96] => | month = December [97] => | doi = 10.1145/224056.224075}} [98] => [99] =>
[100] => Všechno ostatní může být zhotoveno v uživatelských programech, ačkoliv některé ovladače zařízení, implementované jako uživatelské programy, mohou na některých procesorových architekturách vyžadovat privilegia na přístup k I/O hardwaru. [101] => Vzhledem k efektivnosti obsahuje většina mikrojader plánovací a spravovací časovače (porušují tím ale minimální princip). [102] => Start operačního systému, založeného na mikrojádru, vyžaduje [[ovladač zařízení|ovladače zařízení]] (které nejsou součástí jádra). Většinou to znamená, že jsou ovladače zabaleny s jádrem v boot obrazu a jádro podporuje bootstrap (samozaváděcí) protokol, který definuje, kde jsou dané ovladače a jak je spouštět – toto je tradiční boostrap procedura mikrojader L4. Některé mikrojádra tuto proceduru zjednodušují uložením některých klíčových ovladačů přímo do jádra (porušení minimálního principu), například [[LynxOS]] či [[Minix]]. Některé dokonce přidání [[souborový systém|souborového systému]] do jádra ke zjednodušení bootovací procedury. V některých případech, například [[GRUB|GNU GRUB]], systém, založený na mikrojádru, může bootovat pomocí boot loaderu. Takovéto systémy obvykle načtou statické servery pro vytvoření prvotní bootstrap procedury (nebo čekají na obraz OS pro pokračování bootstrap procedury). [103] => Klíčovou komponentou operačního systému, založeného na mikrojádru, je dobrá [[IPC]] a manažer virtuální paměti. Protože všechny úlohy jsou provedeny v uživatelských programech, efektivní komunikace mezi programy je klíčová, daleko důležitější, než je tomu v monolitických jádrech. [104] => [105] => == Výkon == [106] => Na většině mainstreamových procesorů je přepnutí mezi úlohami podstatně pomalejší v systému založeném na mikrojádře, než v monolitickém jádře. [107] => {{cite journal [108] => | last = Liedtke [109] => | first = Jochen [110] => | month = September [111] => | year = 1996 [112] => | title = Towards Real Microkernels [113] => | journal = Communications of the ACM [114] => | volume = 39 [115] => | issue = 9 [116] => | pages = 70–77 [117] => | pmid = [118] => | doi = 10.1145/234215.234473 [119] => | id = [120] => | url = [121] => | language = [122] => | format = [123] => | accessdate = [124] => | laysummary = [125] => | laysource = [126] => | laydate = [127] => | quote = [128] => }} V monolitickém systému je úkol získán jedním systémovým voláním, které potřebuje dva přepínače módů (změna procesorového [[Privilegovaný režim|režimu]], [[CPU Modes|módu]]). V systémech, založených na mikrojádru, jsou úlohy získány odesláním IPC zprávy na server a získávání výsledku probíhá v další IPC zprávě ze serveru. Toto vyžaduje tzv. [[změna kontextu|změnu kontextu]], pokud jsou tedy ovladače implementovány jako procesy, pokud jsou ovladače implementovány jako procedury, vyžaduje to pak volání funkcí. Posílání dat na server a zpět může způsobit extra kopírování, zatímco v monolitickém systému může kernel přistoupit přímo k datům klienta. [129] => [130] => Výkon je proto potenciálním problémem v systémech, založených na mikrojádru. Ačkoliv zkušenosti z prvních generací mikrojader, jako třeba [[Mach (jádro)|Mach]] a [[ChorusOS|Chorus]], ukázaly, že systémy, založené na těchto jádrech, byly velmi výkonově slabé,{{cite conference [131] => | first = Bradley [132] => | last = Chen [133] => | coauthors = Bershad, Brian [134] => | title = The Impact of Operating System Structure on Memory System Performance [135] => | booktitle = 14th ACM Symposium on Operating System Principles [136] => | pages = 120–33 [137] => | publisher = [138] => | month = December [139] => | year = 1993 [140] => | location = Asheville, NC, USA [141] => | accessdate = [142] => | doi = 10.1145/168619.168629 [143] => }} [[Jochen Liedtke]] ukázal, že výkonové problémy Machu byly výsledkem špatného designu, implementace a hlavně pak Machovy velké [[cache]]. Liedtke demonstroval se svým vlastním mikrojádrem [[L4 (jádro)|L4]], že skrz pozorný design, implementaci a hlavně dodržováním principu minimalizace, užívání IPC může být sníženo o více než jeden řád ve srovnání s Machem. Výkon [[L4 (jádro)|L4]] [[Meziprocesová komunikace|IPC]] není stále dodnes poražen v rozmezí dostupných architektur.{{cite conference [144] => | first = Jochen [145] => | last = Liedtke [146] => | authorlink = Jochen Liedtke [147] => | coauthors = Elphinstone, Kevin; Schönberg, Sebastian; Härtig, Hermann; [[Gernot Heiser|Heiser, Gernot]]; Islam, Nayeem; Jaeger, Trent [148] => | title = Achieved IPC performance (still the foundation for extensibility) [149] => | booktitle = 6th Workshop on Hot Topics in Operating Systems [150] => | pages = 28–31 [151] => | publisher = IEEE [152] => | month = May [153] => | year = 1997 [154] => | location = Cape Cod, MA, USA [155] => | url = http://ieeexplore.ieee.org/xpl/RecentCon.jsp?punumber=4643 [156] => | accessdate = [157] => | id = [158] => }} – neplatný odkaz ! [159] => {{cite conference [160] => | first = Charles [161] => | last = Gray [162] => | coauthors = Chapman, Matthew; Chubb, Peter; Mosberger-Tang, David; [[Gernot Heiser|Heiser, Gernot]] [163] => | title = Itanium—a system implementor's tale [164] => | booktitle = USENIX Annual Technical Conference [165] => | pages = 264–278 [166] => | date = April 2005 [167] => | location = Annaheim, CA, USA [168] => | url = https://www.usenix.org/legacy/publications/library/proceedings/usenix05/tech/general/gray.html [169] => }}{{cite conference [170] => | first = Carl [171] => | last = van Schaik [172] => | coauthors = [[Gernot Heiser|Heiser, Gernot]] [173] => | title = High-performance microkernels and virtualisation on ARM and segmented architectures [174] => | booktitle = 1st International Workshop on Microkernels for Embedded Systems [175] => | pages = 11–21 [176] => | publisher = NICTA [177] => | date = January 2007 [178] => | location = Sydney, Australia [179] => | url = http://ertos.nicta.com.au/publications [180] => | accessdate = 2007-04-01 [181] => | id = [182] => | titul = Archivovaná kopie [183] => | datum přístupu = 2011-10-21 [184] => | url archivu = https://web.archive.org/web/20070426092901/http://ertos.nicta.com.au/publications [185] => | datum archivace = 2007-04-26 [186] => | nedostupné = ne [187] => }} {{Wayback|url=http://ertos.nicta.com.au/publications |date=20070426092901 }} {{Citace elektronického periodika |titul=Archivovaná kopie |url=http://ertos.nicta.com.au/publications |datum přístupu=2011-10-21 |url archivu=https://web.archive.org/web/20070426092901/http://ertos.nicta.com.au/publications |datum archivace=2007-04-26 }} [188] => [189] => Zatímco tyto výsledky demonstrují, že slabý výkon systémů, založených na mikrojádrech první generace, není reprezentativní pro druhou generaci jader (jako například L4), stejně to nedokazuje, že systémy, založené na mikrojádru, mohou být postaveny se solidním výkonem. Bylo totiž zjištěno, že monolitický Linux server, konvertovaný na L4, vykazuje výsledek pouze o pár procent lepší, než nativní Linux. [190] => {{cite journal [191] => | first = Hermann [192] => | last = Härtig [193] => | coauthors = Hohmuth, Michael; [[Jochen Liedtke|Liedtke, Jochen]]; Schönberg, Sebastian [194] => | title = The performance of µ-kernel-based systems [195] => | journal = Proceedings of the sixteenth ACM symposium on Operating systems principles [196] => | year = 1997 [197] => | month = October [198] => | url = http://dl.acm.org/citation.cfm?id=266660&dl=ACM&coll= [199] => | pages = 66–77 [200] => | doi = 10.1145/268998.266660 [201] => | isbn = 0-89791-916-5}} Takovéto jednotné servery se ale prakticky vůbec neobjevují. Výhody operačních systémů, založených na mikrojádře, spočívají v poskytování strukturované funkcionality operačního systému na více serverech najednou. [202] => [203] => Mezi komerční multiprocesorové systémy můžeme zařadit například [[operační systém reálného času|real-time systémy]] [[QNX]] a [[Integrity (operační systém)|Integrity]]. U těchto systémů ale nebyly vypracovány podrobné porovnání výkonu s monolitickými systémy a zdá se, že výkon pro tyto výrobce není zas tak primární, spoléhají primárně na rychlé zachycení přerušení (QNX) a jednoduchost z důvodu [[Robustnost (informatika)|robustnosti]] celého systému. Pokus o vytvoření výkonného multiprocesorového operačního systému byl projekt IBM Sawmill Linux. [204] => {{cite conference [205] => | first = Alain [206] => | last = Gefflaut [207] => | coauthors = Jaeger, Trent; Park, Yoonho; [[Jochen Liedtke|Liedtke, Jochen]]; Elphinstone, Kevin J.; Uhlig, Volkmar; Tidswell, Jonathon E.; Deller, Luke; Reuther, Lars [208] => | title = The Sawmill multiserver approach [209] => | booktitle = 9th ACM SIGOPS European Worshop [210] => | location = Kolding, Denmark [211] => | pages = 109–114 [212] => | year = 2000 [213] => }} Tento projekt ale nebyl nikdy dokončen. [214] => [215] => Bylo ukázáno, že ovladače zařízení na uživatelské úrovni se mohou blížit výkonem jádrových ovladačů dokonce i pro zařízení náročné na datový tok a s vysokými nároky na přerušení (Gigabit Ethernet). [216] => {{cite journal [217] => | last = Leslie [218] => | first = Ben [219] => | coauthors = Chubb, Peter; FitzRoy-Dale, Nicholas; Götz, Stefan; Gray, Charles; Macpherson, Luke; Potts, Daniel; Shen, Yueting; Elphinstone, Kevin; [[Gernot Heiser|Heiser, Gernot]] [220] => | year = 2005 [221] => | month = September [222] => | title = User-level device drivers: achieved performance [223] => | journal = Journal of Computer Science and Technology [224] => | volume = 5 [225] => | issue = 20 [226] => | pages = 654–664 [227] => | doi = 10.1007/s11390-005-0654-4}} Z toho se dá mimo jiné usoudit, že výkonné multiserverové systémy jsou možné. [228] => [229] => == Odkazy == [230] => === Reference === [231] => [232] => [233] => === Související články === [234] => * [[Jádro (informatika)|Kernel]] [235] => * [[Monolitické jádro]] [236] => * [[Hybridní jádro]] [237] => [238] => {{Pahýl}} [239] => {{Autoritní data}} [240] => [241] => [[Kategorie:Operační systém]] [242] => [[Kategorie:Jádro operačního systému]] [243] => [244] => [[fi:Käyttöjärjestelmän ydin#Mikroydin]] [245] => [[fr:Noyau de système d'exploitation#Systèmes à micro-noyaux]] [246] => [[it:Kernel#Microkernel]] [] => )
good wiki

Mikrojádro

Mikrojádro Mikrojádro je v informatice typ jádra operačního systému, které je velmi malé a obsahuje jen nejzákladnější funkce (typicky správu paměti a podporu pro plánování procesů a meziprocesové komunikace), čímž se minimalizuje objem běžícího kódu v privilegovaném režimu. Ostatní potřebné části jádra jsou řešeny v uživatelském prostoru jako běžné procesy (resp.

More about us

About

Expert Team

Vivamus eget neque lacus. Pellentesque egauris ex.

Award winning agency

Lorem ipsum, dolor sit amet consectetur elitorceat .

10 Year Exp.

Pellen tesque eget, mauris lorem iupsum neque lacus.

You might be interested in

,'L4 (jádro)','QNX','Gernot Heiser','Jochen Liedtke','UN*X','Meziprocesová komunikace','souborový systém','monolitické jádro','GNU Mach','operační systém','ChorusOS','změna kontextu'

QNX

UN*X