Up Right Betriebssystemkerne/Kleinkernsysteme

Klein/Mikro/NanoKern-Architektur

Kleinkerne, Mikrokerne, Minimalkerne, Nanokerne

Dienste, die bei monolithischen Systemen im Kern sind, werden von sog Servern in höheren Schichten abgewickelt. (vgl. [Tanenbaum92] S.23)

Aufgaben des Kleinkerns:

Virtueller Speicher
IPC (Inter Process Communikation) Kommunikationsinfrastruktur wie
Threads
I/O (Input/Output)
Interruptverarbeitung
Schutzmechanismen
(vgl [DeRoest]) Die Server laufen auf Benutzerebene.

Die Anwendungsprozesse stellen durch den Kern ihre Anfragen an die Server (Trampolinsprung). Dieser Trampolinsprung sollte wenig kosten, ist aber empirisch doch teuer. Deswegen gibt es Kompromisse:
Ladbare Module
Module können nachträglich in den Kern geladen werden (fast bei allen modernen UNIXen gibt es sowas)
Prozesse im Kern
Manche Prozesse können in den Kernaddressraum versenkt werden Idealerweise sollten Prozesse wahlweise im Userlevel oder im Kernraum gestartet werden können.
Der Server kann meist nicht direkt auf die Hardware zugreifen. Im Kern befinden sich die Treiber. In Windows NT gibt es den Begriff Hardware Abstraction Layer (HAL).
Speicherabbildung ist ein weiteres Verfahren, um effizient von einem Server auf die Hardware (z.B Netzwerkpuffer oder Bildschirmadapter) zugreifen zu können.

Beispiel für Dienste, die nun als externe Server im Userlevel laufen:

Wichtige Vorteile der Kleinkernsysteme:
ein klare μ-Kernschnittstelle erzwingt eine modularere Systemstruktur [Liedtke1995]
Die Dienste/Server nutzen die Kernmechanismen wie jedes andere Anwendungsprogramm auch. [Liedke1995]
Daher ist auch eine Fehlfunktion bei einem Server genauso isoliert
Trennung Mechanismus (mechanism) und Politik/Strategie (Policy)
Die Mechanismen werden im Kern implementiert, die Strategie kann vom Nutzer angegeben werden.

Beispiel:

[] Dadurch wird ein System flexibler und anpassbarer [Liedtke1995]
Unterstützung mehrer Betriebsystem-Schnittstellen (Personality)
[Liedtke1995], auch [Open Software - Bericht Brown-University)] Gegenüber Betriebssystemnemulatoren wie Suns WABI hat dieses Vorgehen nach [DeRoest] Geschwindigkeitsvorteile.

Übrigens hatte WindowsNT eine OS/2-Personality, und hat noch eine elementare Posix-Personality (ohne Netz). Aus marketingstrategischen Gründen gibt es diese wohl nicht mehr oder es ist nur sehr elementar ... (Bitte das Gegenteil beweisen :-)

Nach [DeRoest] kann es auch personality neutral services geben, die alle Betriebssystemserver nutzen können

.

Netzwerktransparenz
Ein Serverdienst kann ohne daß der Nutzer es (funktional) merkt, über ein (schnelles) Netz realisiert werden: Lastverteilung und Redundanz lassen sich hiermit realisieren.
Daher eignen sich die Kleinkern-Architektur hervorragend für Verteilte Systeme.
Debugging (Debugging-Personality ...)
(vgl. Open Software - Bericht Brown-University)
Sicherheit
Einen Kleinkern kann man besser verifizieren als einen großen.
Bei krypographischen Verfahren z.B. muß formal bewiesen werden, daß niemand anders auf den Speicher zugreifen kann. Dieses kann nur durch den Betriebssystem sichergestellt werden. (siehe VFiasco Projekt Uni Dresden)
Ein KK-System ist flexibler und einfacher erweiterbarer
Änderungen brauchen nur in einigern Servern gemacht werden.
Hochverfügbarkeit
Paul Leroux, QNX Softwaresystems, weist darauf hin, daß ein Kleinkern durch die verwendung unterschiedlicher Adressräume auch Fehler von Gerätetreibern abfangen kann, was der Hochverfügbarkeit zu gute kommt.
Das Entwickeln von Gerätetreibern ist schwierig B.D. "Gerätetreiber" Vorlesung Tu Dresden: Auch bei WindowsXP seien 85% alle Crashes auf fehlerhafte Treiber zurückzuführen
→ man sollte die Gerätetreiber isolieren
Performancegewinn durch kürzeren kritischen Pfad ( L4 Usermanual Uni South Wales S1)
Bei neuen Mechanismen wächst ein Monolitisches Betriebssystem, beispielsweise ist beim Einbau von NFS in UNIX ein zusätzlicher VFS-Layer hinzugekommen. Microkernsysteme wachsen horizontal, nicht vertikal : Neue Dienste fügen zusätzliche Server hinzu, verlängern aber nicht den kritischen Pfad der häufigst genutzen Operationen.
Jedoch war bei den Systemen der 1. Generation dieser kritische Pfad zu teuer....

Diesen Vorteilen steht die niedrigere Leistung gegenüber (häufigerer und teurer Userlevel/Kern wechsel):
Ein Aufruf einer Applikation einer Treiberfunktion hat folgende Auswirkung (vgl. Vorlesung TU Dresden - Introduction:
IPC mit Driver kostet:

Aufrufe zwischen 2 Betriebsystemdiensten kosten beim Monolitischen Kern nur ein funktionsaufruf, bei der Microernearchitektur soviel wie ein Anwendungsprogramm den Treiber aufruft.

(Aus einem Papier der L4-Designer, das nicht zitiert werden soll:)

1. Generation:

Die Kerne sind durch Abmagerung der monolitischen Kerne entstanden d.h. Design Top Down (bestätigt in [Ruocco2008])

Merkmale: Also:

Problem:

2. Generation:

3. Generation

Bei seL4 ist sogar formal bewiesen worden, dass die Kernimplementierung konsistent mit der formalen Spezifikation ist.

Begrifflichkeit:

Mikro-Kern
Dies ist der historische Architekturbegriff in Abgrenzung zu den monolitischen Kernen
Kleinkern-Systeme
Manchmal geraten die Kerne doch etwas groß, daß man nicht mehr von Micro-Kernen Sprechen kann. Das prominenteste ist WindowsNT/2000.
In dieser Sprechweise wurden nun zu große Mikrokerne umbenannt.
Nano-Kern
nach [SecWikiEn] war das eine hämische Bezeichnung von anderen Kernimplementierern weil der MACH-Kern so groß war

Geschichtlich

(erwähnt in L4 Usermanual Uni South Wales)

Single-Server - Multi Server

Ein Server ist in diesem Zusammenhang ein aktives Objekt/Prozeß, der eine Dienstleistung des Betriebssystem erbringt. Der Server, so ist es ja der Witz der Architektur, läuft außerhalb es Kerns. (Im User-Level oder zwar im Kernadressraum, aber seperat).

Multi-Server
Es gibt mehrere Server, gemeinsam bieten sie die Dienstleitungen des Betiebssystems an. Nach der Grundidee sollte jeder Dienst von einem separaten Server implementiert sein.
Single Server
Alle Dienste werden von einem Server erbracht.
Die Single-Server sind meist die Emulatoren herkömmlicher Systeme, wie z.B. ein BSD-Server auf MACH. Lange Jahre blieben die Kleinkernsysteme meist nur in Akademischer Diskussion, und die Notlösungen sind geblieben.

GNU HURD und das Sawmill-Projekt kümmern sich um die Multi-Server ideen.

An sich ist das Multi-Server-Paradigma ein wichtiger Grund auf Kleinkernsysteme zu setzen: Die Verteilten Systeme bestehen aus Rechenknoten. Die Server werden auf die verschiedenen Rechenknoten verteilt, jeder Rechenknoten ist mit dem Kleinkern ausgestattet.

Bei Techniken wie Storage Area Networks (SAN) usw. rufen eigentlich nach diesen modernen Betriebssystemtechniken ...

Ingenieurmäßiger Einsatz der Microkerne

Bei speziellen Anforderungen schreibt man spezielle Server (Customizing) (Es ist nun überflüssig geworden neue Betriebssysteme ganz von vorne (from scratch) zu entwickeln ...
Es gibt dann einen Baukasten für Betriebssysteme, mit hohem Konfigurationsmöglichkeiten und -bedarf.

Links zu weiteren Diskussionen

Linux is obsolete ?
Diskussion Tanenbaum (u.a. Autor von [Tanenbaum92] mit Linux-Freunden. Dabei geht es auch um die Thematik Minimalkern gegen Monolitik
L. Linus Torvalds about the microkernels again, 2006.05.09
These: Das Microkerneldesign führe zu verschiedenen Addressräumen dieses führe zu kompexerer Programmierung ohne gemeinsamen Speicher.
Illustration: ein Fileserver ruft einen Netzwerkserver auf (z.b. NFS), usw. es kann sehr leicht zyklische Abhängigkeiten geben - dies muss sauber designed werden!
Grundsätzlich ist Komponentenweise ist ein besseres Design: MS DOS war nicht sicherer wie Unix/Linux:
Eine bessere Antwort von J.Shapiro Hopkins University und Andrew Tanenbaum

Weitere Links

[SecWikiEn]
Engl. Wikipedia über Microkerne
Informatik- und Netzwerkverein Ravensburg e.V Rudolf Weber