In der Informatik ist ein Mikrokern der nah-minimale Betrag der Software, die die Mechanismen zur Verfügung stellen kann, musste ein Betriebssystem (OS) durchführen. Diese Mechanismen schließen auf niedriger Stufe Adressraum-Management ein, fädeln Management und Zwischenprozess-Kommunikation (IPC) ein. Wenn die Hardware vielfache Ringe oder Zentraleinheitsweisen zur Verfügung stellt, ist der Mikrokern die einzige Softwaredurchführung am privilegiertesten Niveau (allgemein gekennzeichnet als Oberaufseher oder Kernweise). Traditionelle Betriebssystemfunktionen, wie Gerät-Fahrer, Protokoll-Stapel und Dateisysteme, werden vom Mikrokern entfernt, um im Benutzerraum zu laufen. In der Quellcodegröße neigen Mikrokerne dazu, unter 10,000 Linien des Codes als eine allgemeine Regel zu sein. Der Kern von MINIX, hat zum Beispiel weniger als 6,000 Linien des Codes. Kerne, die größer sind als 20,000 Linien, werden allgemein als Mikrokerne nicht betrachtet.

Mikrokerne haben sich in den 1980er Jahren als eine Antwort auf Änderungen in der Computerwelt und mehrere Herausforderungen entwickelt, die vorhandene "Monokerne" an diese neuen Systeme anpassen. Neue Gerät-Fahrer, Protokoll-Stapel, Dateisysteme und andere auf niedriger Stufe Systeme wurden die ganze Zeit entwickelt, codieren, der normalerweise im monolithischen Kern gelegen wurde, und so verlangt hat, dass beträchtliche Arbeit und sorgfältiges Codemanagement daran gearbeitet hat. Mikrokerne wurden mit der Idee entwickelt, dass alle diese Dienstleistungen als Benutzerraumfährte, wie irgendwelcher anderer durchgeführt würden, ihnen erlaubend, auf monolithisch gearbeitet und angefangen und wie jedes andere Programm angehalten zu werden. Das würde diesen Dienstleistungen nicht nur erlauben, leichter darauf gearbeitet zu werden, sondern auch hat den Kerncode getrennt, um ihm zu erlauben, fein abgestimmt zu werden, ohne sich über unbeabsichtigte Nebenwirkungen zu sorgen. Außerdem würde es völlig neuen Betriebssystemen erlauben, auf einem allgemeinen Kern "aufgebaut" zu werden, OS Forschung helfend.

Mikrokerne waren ein sehr heißes Thema in den 1980er Jahren, als die ersten verwendbaren lokalen Bereichsnetze eingeführt wurden. Dieselben Mechanismen, die dem Kern erlaubt haben, in den Benutzerraum auch verteilt zu werden, haben dem System erlaubt, über Netzverbindungen verteilt zu werden. Die ersten Mikrokerne, namentlich Mach, herausgestellt, enttäuschende Leistung, aber die innewohnenden Vorteile zu haben, ist so groß geschienen, dass es eine Hauptlinie der Forschung ins Ende der 1990er Jahre war. Jedoch während dieser Zeit ist die Geschwindigkeit von Computern außerordentlich in Bezug auf den Netzwerkanschluss von Systemen gewachsen, und die Nachteile in der Leistung sind gekommen, um die Vorteile in Entwicklungsbegriffen zu überwältigen. Viele Versuche wurden gemacht, die vorhandenen Systeme anzupassen, um bessere Leistung zu haben, aber die Gemeinkosten waren immer beträchtlich, und die meisten dieser Anstrengungen haben verlangt, dass die Benutzerraumfährte in den Kern zurückgekehrt wurden. Vor 2000 hatten die meisten groß angelegten (einem Mach ähnlichen) Anstrengungen geendet, obwohl OpenStep einen angepassten Mach-Kern genannt XNU verwendet hat, der jetzt im OS bekannt als Darwin verwendet wird, der der offene Quellteil von Mac OS X ist

Obwohl die Hauptarbeit an Mikrokernen größtenteils geendet hat, haben Experimentatoren Entwicklung fortgesetzt. Es ist seitdem gezeigt worden, dass viele der Leistungsprobleme von früheren Designs nicht eine grundsätzliche Voraussetzung des Konzepts, aber stattdessen wegen des Wunsches des Entwerfers waren, Einzwecksysteme zu verwenden, um so viele dieser Dienstleistungen wie möglich durchzuführen. Das Verwenden einer pragmatischeren Annäherung an das Problem, einschließlich des Zusammenbau-Codes und das Verlassen auf den Verarbeiter, um in der Software normalerweise unterstützte Konzepte geltend zu machen, haben zu einer neuen Reihe von Mikrokernen mit der drastisch verbesserten Leistung geführt. Der historische Begriff nanokernel ist gebraucht worden, um moderne Hochleistungsmikrokerne von früheren Durchführungen zu unterscheiden, die noch viele Systemdienstleistungen enthalten haben. Jedoch, da nanokernels fast ihre Mikrokernahnen ersetzt haben, ist der Begriff in den Nichtgebrauch gefallen.

Mikrokerne sind nah mit exokernels verbunden.

Sie haben auch mit Hyperschirmen, viel gemeinsam

aber die Letzteren erheben keinen Anspruch auf minimality und werden zum Unterstützen virtueller Maschinen spezialisiert; tatsächlich findet der L4 Mikrokern oft Gebrauch in einer Hyperschirm-Kapazität.

Einführung

Früh waren Betriebssystemkerne teilweise ziemlich klein, weil Computergedächtnis beschränkt wurde. Da die Fähigkeit zu Computern gewachsen ist, ist die Zahl von Geräten, die der Kern auch kontrollieren musste, gewachsen. Durch die frühe Geschichte von Unix waren Kerne allgemein klein, wenn auch jene Kerne Gerät-Fahrer und Dateisystemverwalter enthalten haben. Als Adressräume von 16 bis 32 Bit zugenommen haben, wurde Kerndesign durch die Hardware-Architektur nicht mehr befestigt, und Kerne haben begonnen zu wachsen.

Berkeley Software Distribution (BSD) von Unix hat das Zeitalter von großen Kernen begonnen. Zusätzlich zum Funktionieren eines grundlegenden Systems, das aus der Zentraleinheit, den Platten und den Druckern besteht, hat BSD angefangen, zusätzliche Dateisysteme, ein ganzer TCP/IP Netzwerkanschluss des Systems und mehrerer "virtueller" Geräte hinzuzufügen, die den vorhandenen Programmen erlaubt haben, unsichtbar über das Netz zu arbeiten. Dieses Wachstum hat viele Jahre lang weitergegangen, auf Kerne mit Millionen von Linien des Quellcodes hinauslaufend. Infolge dieses Wachstums waren Kerne für Programmfehler anfälliger und sind immer schwieriger geworden aufrechtzuerhalten.

Der Mikrokern wurde entworfen, um das zunehmende Wachstum von Kernen und den Schwierigkeiten zu richten, die mit ihnen gekommen sind. In der Theorie berücksichtigt das Mikrokerndesign leichteres Management des Codes wegen seiner Abteilung in Benutzerraumdienstleistungen. Das berücksichtigt auch vergrößerte Sicherheit und Stabilität, die sich aus dem reduzierten Betrag des Codes ergibt, der in der Kernweise läuft. Zum Beispiel, wenn ein Netzwerkanschlussdienst wegen der Pufferüberschwemmung abstürzen würde, würde nur das Netzwerkanschlussdienstgedächtnis verdorben, den Rest des Systems noch funktionell verlassend.

Zwischenprozess-Kommunikation

Zwischenprozess-Kommunikation (IPC) ist jeder Mechanismus, der getrennten Prozessen erlaubt, mit einander, gewöhnlich durch das Senden von Nachrichten zu kommunizieren. Geteiltes Gedächtnis ist genau genommen auch ein Zwischenprozess-Nachrichtenmechanismus, aber die Abkürzung, die IPC gewöhnlich nur auf den Nachrichtenübergang verweist, und es ist der Letztere, der für Mikrokerne besonders wichtig ist. IPC erlaubt dem Betriebssystem, aus mehreren kleinen Programmen genannt Server gebaut zu werden, die durch andere Programme auf dem System verwendet werden, das über IPC angerufen ist. Die meisten oder die ganze Unterstützung für die peripherische Hardware werden auf diese Mode, mit Servern für Gerät-Fahrer, Netzprotokoll-Stapel, Dateisysteme, Grafik usw. behandelt.

IPC kann gleichzeitig oder asynchron sein. Asynchroner IPC ist der Netzkommunikation analog: Der Absender entsendet eine Nachricht und setzt fort durchzuführen. Die Empfänger-Kontrollen (Wahlen) für die Verfügbarkeit der Nachricht durch den Versuch eines Erhaltens, oder werden dazu über einen Ankündigungsmechanismus alarmiert. Asynchroner IPC verlangt, dass der Kern Puffer und Warteschlangen für Nachrichten aufrechterhält, und sich mit Pufferüberschwemmungen befasst; es verlangt auch das doppelte Kopieren von Nachrichten (Absender zum Kern und Kern zum Empfänger). In gleichzeitigem IPC, die erste Partei (Absender oder Empfänger) Blöcke, bis die andere Partei bereit ist, den IPC durchzuführen. Es verlangt Pufferung oder vielfache Kopien nicht, aber das implizite Rendezvous kann Programmierung heikel machen. Die meisten Programmierer bevorzugen asynchron senden, und gleichzeitig erhalten.

Mikrokerne der ersten Generation haben normalerweise gleichzeitigen sowie asynchronen IPC unterstützt, und haben unter der schlechten IPC Leistung gelitten. Jochen Liedtke hat das Design und die Durchführung der IPC Mechanismen als der zu Grunde liegende Grund für diese schlechte Leistung identifiziert. In seinem L4 Mikrokern hat er für Methoden den Weg gebahnt, die IPC-Kosten durch eine Größenordnung gesenkt haben. Diese schließen einen IPC Systemanruf ein, der ein Senden sowie eine erhalten Operation unterstützt, alle IPC gleichzeitig machend, und so viele Daten wie möglich in Registern passierend. Außerdem hat Liedtke das Konzept des direkten Prozess-Schalters eingeführt, wo während einer IPC Ausführung ein (unvollständiger) Zusammenhang-Schalter vom Absender direkt zum Empfänger durchgeführt wird. Wenn, als in L4, Teil oder der ganzen Nachricht in Registern passiert wird, überträgt das den Teil im Register der Nachricht ohne jedes Kopieren überhaupt. Außerdem werden die Gemeinkosten, den Planer anzurufen, vermieden; das ist im allgemeinen Fall besonders vorteilhaft, wo IPC in einem RPC-Typ Mode von einem Kunden verwendet wird, der einen Server anruft. Eine andere Optimierung, genannt faule Terminplanung, vermeidet, Terminplanungswarteschlangen während IPC durch das Verlassen von Fäden zu überqueren, die während IPC in der bereiten Warteschlange blockieren. Sobald der Planer angerufen wird, bewegt er solche Fäden zur passenden Warteschlange. Als in vielen Fällen wird ein Faden frei gemacht vor der folgenden Planer-Beschwörung spart diese Annäherung bedeutende Arbeit. Ähnliche Annäherungen sind durch QNX und MINIX 3 seitdem angenommen worden.

In einem Client/Server-System ist der grösste Teil der Kommunikation im Wesentlichen gleichzeitig, selbst wenn mit asynchronen Primitiven, weil die typische Operation ein Kunde ist, der einen Server anruft und dann auf eine Antwort wartet. Da es auch sich zur effizienteren Durchführung leiht, folgen moderne Mikrokerne allgemein L4'S-Leitung und stellen nur einen gleichzeitigen IPC Primitiven zur Verfügung. Asynchroner IPC kann auf der Spitze durch das Verwenden von Helfer-Fäden durchgeführt werden. Jedoch haben Versionen von in kommerziellen Produkten aufmarschiertem L4 es notwendig gefunden, einen asynchronen Ankündigungsmechanismus hinzuzufügen, asynchrone Kommunikation besser zu unterstützen. Dieser signalähnliche Mechanismus trägt Daten nicht und verlangt deshalb Pufferung durch den Kern nicht.

Da gleichzeitiger IPC die erste Partei blockiert, bis der andere bereit ist, uneingeschränkter Gebrauch zu toten Punkten leicht führen konnte. Außerdem konnte ein Kunde einen Angriff der Leugnung des Dienstes auf einem Server leicht organisieren, indem er eine Bitte gesandt hat und nie versucht hat, die Antwort zu erhalten. Deshalb muss gleichzeitiger IPC ein Mittel zur Verfügung stellen, das unbestimmte Blockieren zu verhindern. Viele Mikrokerne stellen Pausen auf IPC-Anrufen zur Verfügung, die die blockierende Zeit beschränken. In der Praxis ist Auswahl vernünftiger Pause-Werte schwierig, und Systeme verwenden fast unvermeidlich unendliche Pausen für Kunden und Nullpausen für Server. Demzufolge ist die Tendenz zur nicht Versorgung willkürlicher Pausen, aber nur einer Fahne, die anzeigt, dass der IPC sofort scheitern sollte, wenn der Partner nicht bereit ist. Diese Annäherung stellt effektiv eine Wahl der zwei Pause-Werte der Null und Unendlichkeit zur Verfügung. Neue Versionen von L4 und MINIX sind diesen Pfad heruntergekommen (ältere Versionen von L4 haben Pausen verwendet, wie QNX tut).

Server

Mikrokernserver sind im Wesentlichen Dämon-Programme wie irgendwelcher andere, außer dass der Kern einigen von ihnen Vorzüge gewährt, mit Teilen des physischen Gedächtnisses aufeinander zu wirken, die sonst von Grenzen zu den meisten Programmen sind. Das erlaubt einige Server, besonders Gerät-Fahrer, um direkt mit der Hardware aufeinander zu wirken.

Ein grundlegender Satz von Servern für einen Mehrzweckmikrokern schließt Dateisystemserver, Gerät-Fahrer Server ein, Server, Anzeigeserver und Benutzerschnittstelle-Gerät-Server vernetzend. Dieser Satz von Servern (gezogen von QNX) stellt grob den Satz von Dienstleistungen zur Verfügung, die von Unix monolithischer Kern angeboten sind. Die notwendigen Server werden beim Systemanlauf angefangen und stellen Dienstleistungen, wie Datei, Netz und Gerät-Zugang zu gewöhnlichen Anwendungsprogrammen zur Verfügung. Mit solchen Servern, die in der Umgebung einer Benutzeranwendung laufen, ist Server-Entwicklung der gewöhnlichen Anwendungsentwicklung, aber nicht dem bauen-und-starten für die Kernentwicklung erforderlichen Prozess ähnlich.

Zusätzlich können viele "Unfälle" durch das einfache Aufhören und das Wiederstarten des Servers korrigiert werden. Jedoch wird ein Teil des Systemstaates mit dem Mangel-Server verloren, folglich verlangt diese Annäherung, dass Anwendungen mit Misserfolg fertig werden. Ein gutes Beispiel ist ein für TCP/IP Verbindungen verantwortlicher Server: Wenn dieser Server wiederangefangen wird, werden Anwendungen eine "verlorene" Verbindung, ein normales Ereignis im vernetzten System erfahren. Für andere Dienstleistungen wird Misserfolg weniger erwartet und kann Änderungen zum Anwendungscode verlangen. Für QNX wird Wiederanlauffähigkeit als der QNX Hohes Verfügbarkeitswerkzeug angeboten.

Um alle Server restartable zu machen, haben sich einige Mikrokerne auf das Hinzufügen verschiedener datenbankähnlicher Methoden wie Transaktionen, Erwiderung und checkpointing konzentriert, um wesentlichen Staat über einzelne Server-Wiederanfänge zu bewahren. Ein Beispiel ist ChorusOS, der für Hochverfügbarkeitsanwendungen in der Fernmeldewelt gemacht wurde. Chor hat Eigenschaften eingeschlossen, um jedem "richtig geschriebenen" Server zu erlauben, jederzeit mit Kunden wiederangefangen zu werden, die jene Server verwenden, die Pause machen werden, während der Server sich in seinen ursprünglichen Staat zurückgebracht hat. Jedoch sind solche Kerneigenschaften mit dem minimality Grundsatz unvereinbar, und werden so in modernen Mikrokernen nicht zur Verfügung gestellt, die sich stattdessen auf passende Benutzerniveau-Protokolle verlassen.

Gerät-Fahrer

Gerät-Fahrer führen oft direkten Speicherzugang (DMA) durch, und können deshalb willkürlichen Positionen des physischen Gedächtnisses, einschließlich über Kerndatenstrukturen schreiben. Solchen Fahrern muss deshalb vertraut werden. Es ist ein häufiger Irrtum, dass das bedeutet, dass sie ein Teil des Kerns sein müssen. Tatsächlich ist ein Fahrer nicht von Natur aus mehr oder weniger vertrauenswürdig, indem er ein Teil des Kerns ist.

Während das Laufen eines Gerät-Fahrers im Benutzerraum den Schaden nicht notwendigerweise reduziert, den ein sich schlecht benehmender Fahrer verursachen kann, in der Praxis ist es für die Systemstabilität in Gegenwart vom Buggy vorteilhaft (aber nicht böswillig) Fahrer: Speicherzugang-Übertretungen durch den Fahrer-Code selbst (im Vergleich mit dem Gerät) können noch durch die Speichermanagement-Hardware gefangen werden. Außerdem sind viele Geräte nicht DMA-fähig, ihre Fahrer können unvertraut gemacht werden, indem sie sie im Benutzerraum führen. Kürzlich, eine steigende Zahl von Computern zeigen IOMMUs, von denen viele verwendet werden können, um einen Zugang eines Geräts zum physischen Gedächtnis zu beschränken. (Großrechner von IBM haben IO MMUs seit IBM System/360 Model 67 und System/370 gehabt.) Das erlaubt auch Benutzerweise-Fahrern, unvertraut zu werden.

Benutzerweise-Fahrer datieren wirklich Mikrokerne zurück. Michigan Terminal System (MTS) 1967 hat Benutzerraumfahrer (einschließlich seiner Dateisystembetreuung), das erste mit dieser Fähigkeit zu entwerfende Betriebssystem unterstützt.

Historisch waren Fahrer weniger von einem Problem, weil die Zahl von Geräten klein und irgendwie vertraut war, auch sie im Kern hat das Design vereinfacht und hat potenzielle Leistungsprobleme vermieden. Das hat zum traditionellen Fahrer im Kernstil von Unix, Linux und Windows geführt.

Mit der Proliferation von verschiedenen Arten der Peripherie hat der Betrag des Fahrer-Codes eskaliert, und in modernen Betriebssystemen beherrscht den Kern in der Codegröße.

Wesentliche Bestandteile und minimality

Da ein Mikrokern erlauben muss, willkürliche Betriebssystemdienstleistungen auf der Spitze zu bauen, muss er etwas Kernfunktionalität zur Verfügung stellen. An einem Minimum schließt das ein:

• einige Mechanismen, um sich mit Adressräumen zu befassen — ist das für den Betriebsspeicherschutz erforderlich;
• etwas Ausführungsabstraktion, um Zentraleinheitszuteilung zu führen — fädelt normalerweise ein oder Planer-Aktivierungen; und
• Zwischenprozess-Kommunikation — erforderlich, Server anzurufen, die in ihren eigenen Adressräumen laufen.

Für dieses minimale Design wurde durch den Kern von Brinch Hansen und den Hyperschirm des VM von IBM den Weg gebahnt. Es ist im minimality Grundsatz von Liedtke seitdem formalisiert worden:

Etwas anderes kann in einem usermode Programm getan werden, obwohl Gerät-Fahrer durchgeführt haben, weil der Benutzerprogramm-Mai auf einigen Verarbeiter-Architekturen spezielle Vorzüge verlangt, auf Eingabe/Ausgabe-Hardware zuzugreifen.

Verbunden mit dem minimality Grundsatz, und ebenso wichtig für das Mikrokerndesign, ist die Trennung des Mechanismus und der Politik, es ist, was den Aufbau von willkürlichen Systemen oben auf einem minimalen Kern ermöglicht. Jede in den Kern eingebaute Politik kann am Benutzerniveau nicht überschrieben werden und beschränkt deshalb die Allgemeinheit des Mikrokerns.

In Benutzerniveau-Servern durchgeführte Politik kann geändert werden, indem sie die Server ersetzt wird (oder die Anwendung zwischen konkurrierenden Servern wählen lässt, die ähnliche Dienstleistungen anbieten).

Für die Leistungsfähigkeit enthalten die meisten Mikrokerne Planer und führen Zeitmesser, in der Übertretung des minimality Grundsatzes und des Grundsatzes der Politikmechanismus-Trennung.

Springen Sie auf (das Starten) eines mikrokernbasierten Systems verlangt Gerät-Fahrer, die nicht ein Teil des Kerns sind. Normalerweise bedeutet das, dass sie mit dem Kern im Stiefelimage paketiert werden, und der Kern ein Stiefelstrippe-Protokoll unterstützt, das definiert, wie die Treiber gelegen und angefangen werden; das ist das traditionelle Stiefelstrippe-Verfahren von L4 Mikrokernen. Einige Mikrokerne vereinfachen das durch das Stellen einiger Schlüsselfahrer innerhalb des Kerns (in der Übertretung des minimality Grundsatzes), LynxOS und ursprünglicher Minix sind Beispiele. Einige schließen sogar ein Dateisystem in den Kern ein, um das Starten zu vereinfachen. Ein mikrokernbasiertes System kann über den Mehrstiefel vereinbaren Stiefellader starten. Solche Systeme laden gewöhnlich statisch verbundene Server, um eine anfängliche Stiefelstrippe zu machen oder ein OS Image zu besteigen, um fortzusetzen, zu urladen.

Ein Schlüsselbestandteil eines Mikrokerns ist ein gutes IPC System und Design des virtuellen Speicherbetriebsleiters, das erlaubt, das Seitenschuld-Berühren und Tauschen in usermode Servern auf eine sichere Weise durchzuführen. Da alle Dienstleistungen durch usermode Programme durchgeführt werden, sind effiziente Mittel der Kommunikation zwischen Programmen viel mehr notwendig als in monolithischen Kernen. Das Design des IPC Systems macht oder bricht einen Mikrokern. Um wirksam zu sein, muss das IPC System nicht niedrig oben nur haben, sondern auch gut mit der Zentraleinheitsterminplanung aufeinander wirken.

Leistung

Auf den meisten Hauptströmungsverarbeitern, einen Dienst erhaltend, ist in einem mikrokernbasierten System von Natur aus teurer als ein monolithisches System. Im monolithischen System wird der Dienst durch einen einzelnen Systemanruf erhalten, der zwei Weise-Schalter (Änderungen des Rings des Verarbeiters oder Zentraleinheitsweise) verlangt. Im mikrokernbasierten System wird der Dienst durch das Senden einer IPC Nachricht an einen Server und das Erreichen des Ergebnisses in einer anderen IPC Nachricht vom Server erhalten. Das verlangt einen Zusammenhang-Schalter, wenn die Treiber als Prozesse oder ein Funktionsanruf durchgeführt werden, wenn sie als Verfahren durchgeführt werden. Außerdem kann der Übergang wirklicher Daten zum Server und zurück das Extrakopieren oben übernehmen, während in einem monolithischen System der Kern auf die Daten in den Puffern des Kunden direkt zugreifen kann.

Leistung ist deshalb ein potenzielles Problem in Mikrokernsystemen. Tatsächlich hat die Erfahrung von Mikrokernen der ersten Generation wie Mach und ChorusOS gezeigt, dass Systeme auf ihnen durchgeführt sehr schlecht gestützt haben.

Jedoch hat Jochen Liedtke gezeigt, dass die Leistungsprobleme des Machs das Ergebnis des schlechten Designs und der Durchführung, und spezifisch des übermäßigen Seitenfußabdrucks des geheimen Lagers des Machs waren.

Liedtke hat mit seinem eigenen L4 Mikrokern demonstriert, dass durch das sorgfältige Design und die Durchführung, und besonders durch den folgenden der minimality Grundsatz IPC Kosten durch mehr als eine Größenordnung im Vergleich zum Mach reduziert werden konnten. L4's IPC Leistung ist noch über eine Reihe von Architekturen unübertroffen.

Während diese Ergebnisse demonstrieren, dass die schlechte Leistung von auf Mikrokernen der ersten Generation gestützten Systemen für Kerne der zweiten Generation wie L4 nicht vertretend ist, setzt das keinen Beweis ein, dass mikrokernbasierte Systeme mit der guten Leistung gebaut werden können. Es ist gezeigt worden, dass ein monolithischer zu L4 getragener Server von Linux nur einiges Prozent oben über den Eingeborenen Linux ausstellt.

Jedoch stellt solch ein System des einzelnen Servers aus wenige, falls etwa, der Vorteil-Mikrokerne sollen zur Verfügung stellen, indem sie Betriebssystemfunktionalität in getrennte Server strukturieren.

Mehrere kommerzielle Mehrserver-Systeme, bestehen insbesondere die Echtzeitsysteme QNX und Integrität. Kein umfassender Vergleich der Leistung hinsichtlich monolithischer Systeme ist für jene Mehrserver-Systeme veröffentlicht worden. Außerdem scheint Leistung nicht, die überwiegende Sorge für jene kommerziellen Systeme zu sein, die stattdessen zuverlässig schnelle Unterbrechungsbehandlungsansprechzeiten (QNX) und Einfachheit wegen der Robustheit betonen. Ein Versuch, einen Hochleistungsmehrserver Betriebssystem zu bauen, war das Projekt von IBM Sawmill Linux.

Jedoch wurde dieses Projekt nie vollendet.

Es ist inzwischen gezeigt worden, dass Benutzerniveau-Gerät-Fahrer in der Nähe von der Leistung von Fahrern im Kern sogar für solchen hohen Durchfluss, Geräte der hohen Unterbrechung als Gigabit Ethernet kommen können. Das scheint anzudeuten, dass Hochleistungsmehrserver-Systeme möglich sind.

Sicherheit

Die Sicherheitsvorteile von Mikrokernen sind oft besprochen worden. Im Zusammenhang der Sicherheit ist der minimality Grundsatz von Mikrokernen eine direkte Folge des Grundsatzes von kleinstem Vorzug, gemäß dem der ganze Code nur die Vorzüge haben sollte, musste erforderliche Funktionalität zur Verfügung stellen. Minimality verlangt, dass eine vertraute Rechenbasis (TCB) eines Systems minimal behalten werden sollte. Weil der Kern (der Code, der in der privilegierten Weise der Hardware durchführt) immer ein Teil des TCB ist, ist das Minimieren davon in einem geSicherheitssteuerten Design natürlich.

Folglich sind Mikrokerndesigns für Systeme verwendet worden, die für Anwendungen der hohen Sicherheit, einschließlich KeyKOS, EROS und militärischer Systeme entworfen sind. Tatsächlich haben allgemeine Kriterien (CC) am höchsten Versicherungsniveau (Evaluation Assurance Level (EAL) 7) eine ausführliche Voraussetzung dass das Ziel der Einschätzung, eine Anerkennung der praktischen Unmöglichkeit "einfach" sein, wahre Zuverlässigkeit für ein kompliziertes System zu gründen.

Die dritte Generation

Die neue Arbeit an Mikrokernen hat sich auf formelle Spezifizierungen der Kern-API und formelle Beweise von Sicherheitseigenschaften der API konzentriert. Das erste Beispiel davon ist ein mathematischer Beweis der Beschränkungsmechanismen in EROS, der auf einem vereinfachten Modell der EROS API gestützt ist. Mehr kürzlich ist eine umfangreiche Auswahl von maschinenkarierten Beweisen der Eigenschaften des Schutzmodells von seL4, einer Version von L4 durchgeführt worden.

Das hat dazu geführt, was der dritten Generation Mikrokerne, genannt wird

charakterisiert durch eine Sicherheitsorientierte API mit dem Quellenzugang, der von Fähigkeiten, Virtualisierung als eine erstklassige Sorge kontrolliert ist, nähert sich Roman dem Kernquellenmanagement,

und eine Designabsicht der Eignung für die formelle Analyse, außer der üblichen Absicht der hohen Leistung. Beispiele sind Coyotos, seL4, Nova,

und Misserfolg. OC.

Im Fall von seL4 ist die ganze formelle Überprüfung der Durchführung, d. h. ein mathematischer Beweis erreicht worden, dass die Durchführung des Kerns mit seiner formellen Spezifizierung im Einklang stehend ist. Das stellt eine Garantie zur Verfügung, dass sich die Eigenschaften über die API erwiesen haben, wirklich halten für den echten Kern, einen Grad der Versicherung, die sogar CC EAL7 übertrifft.

Nanokernel

Der Begriff nanokernel oder picokernel, der historisch verwiesen ist auf:

1. Ein Kern, wo die Summe des Kerncodes, d. h. Codedurchführung in der privilegierten Weise der Hardware, sehr klein ist. Der Begriff picokernel wurde manchmal gebraucht, um weiter kleine Größe zu betonen. Der Begriff nanokernel wurde von Jonathan S. Shapiro in der Zeitung KeyKOS Architektur von NanoKernel ins Leben gerufen. Es war eine sardonische Antwort auf das Mach, das behauptet hat, ein Mikrokern zu sein, im Wesentlichen unstrukturiert monolithisch seiend, und langsamer als die Systeme es sich bemüht hat zu ersetzen. Nachfolgender Wiedergebrauch und Antwort auf den Begriff, einschließlich des picokernel Prägenes, weisen darauf hin, dass der Punkt größtenteils verpasst wurde. Sowohl nanokernel als auch picokernel sind nachher gekommen, um dieselbe Bedeutung durch den Begriff Mikrokern ausdrücken zu lassen.
2. Eine Virtualisierungsschicht unter einem Betriebssystem; das wird mehr richtig einen Hyperschirm genannt.
3. Eine Hardware-Abstraktionsschicht, die den Tiefststand-Teil eines Kerns bildet, hat manchmal gepflegt, Echtzeitfunktionalität dem normalen OS'S wie Adeos zur Verfügung zu stellen.

Es gibt auch mindestens einen Fall, wo der Begriff nanokernel gebraucht wird, um sich nicht auf einen kleinen Kern, aber denjenigen zu beziehen, der eine Nanosekunde-Uhr-Entschlossenheit unterstützt.

Siehe auch

• Kern (Informatik)
• Exokernel, eine Forschungskernarchitektur mit mehr Minimalist-Annäherung an die Kerntechnologie.
• Hybrider Kern
• Monolithischer Kern
• Kernmodul von Loadable
• Vertraute Rechenbasis

Weiterführende Literatur

• wissenschaftliche Artikel über Mikrokerne (auf CiteSeer), einschließlich:

• - die grundlegende QNX Verweisung.

• - die grundlegende zuverlässige Verweisung.

• - die grundlegende Mach-Verweisung.
• Seite von MicroKernel vom Portland Muster-Behältnis
• Die Tanenbaum-Torvalds diskutieren
• Die Tanenbaum-Torvalds-Debatte, am 1992.01.29
• Tanenbaum, A. S. "Können wir Betriebssysteme zuverlässig und sicher machen?".
• Torvalds, L. Linus Torvalds über die Mikrokerne wieder, am 2006.05.09
• Shapiro, J. "das Entlarven von letztem Linus".
• Tanenbaum, A. S. "Tanenbaum-Torvalds Debatte: Zweiter Teil".