Der folgende Artikel wird ganz allgemein Informationen darüber geben, was ein Kernel ist, wozu er da ist und welche unterschiedlichen Arten es gibt. Es ist durchaus empfehlenswert, den Artikel von vorne bis hinten durchzulesen und keine Kapitel auszulassen. Ansonsten könnte die Sache mit dem Verständnis etwas schwer werden… ;)

1. Was ist ein Kernel?
2. Welche unterschiedliche Kernelarten gibt es?
   1. Monolithische Kernel
   2. Microkernel
   3. Exokernel und ähnliche
3. Was sollte ein Kernel mindestens können?

Zuerst einmal sollte natürlich die Frage geklärt werden, was ein Kernel denn überhaupt ist. Was genau ein Kernel ist steckt in gewisser Weise schon in dem Wort „Kernel“: Er ist der (zumindest auf der Softwareseite) Kern eines Computersystems. Ohne ihn läuft nichts.

Was genau der Kernel nun aber tut ist nicht so einfach zu klären. Denn die Aufgaben eines Kernels variieren sehr stark mit dem Design - der Idee, die hinter dem Konzept steckt.

Kernel kann man allgemein in etwa drei Gruppen einteilen. Bei der Einteilung geht es in erster Linie um den Aufbau des Kernels in sich. Es gibt Kernel, die einen eher „geschlossenen“ Aufbau bevorzugen bei dem der Kernel viele Bestandteile eines Betriebssystems schon enthält und solche, die nur die grundsätzlichsten Funktionen anbieten und alles weitere dynamisch nachladen.

Im Anwenderland sind diese Kernel wohl am weitesten verbreitet. Repräsentanten sind vor allem Windows-Systeme und Unix-Systeme wie zum Beispiel Linux. Die Art von Kernel, der monolithische Kernel, zielt darauf ab, möglichst alles, was zu einem Betriebssystem gehört im Kernelbereich anzusiedeln.

Es werden also möglichst viele Treiber direkt mit in den Kernel aufgenommen.

Daraus ergeben sich sowohl Vorteile als auch Nachteile. Von dieser Art des Zusammenspiels zwischen Kernel und Treibern profitiert vor allem die Geschwindigkeit. Die Kommunikation zwischen Treiber und Kernel, und damit auch die Kommunikation zwischen Treiber und Hardware, läuft ohne größere Umwege oder gar direkt ab, wodurch aufwendige (und damit auch zeitintensive) Weiterleitungen über Nachrichtenkanäle entfallen. Allerdings ist das Konzept nicht sehr dynamisch und kann schlecht auf „Unvorhergesehenes“ wie neue Hardware oder allgemein neue Entwicklungen in der Computerindustrie reagieren - im schlechtesten Fall müsste der komplette Kernel dann angepasst werden.

Um aus diesem eher statischen Konzept zu entfliehen bemüht sich Linux z.B. um mehr Modularität, indem es nachladbare Module anbietet. Dieses Konzept ist an das der Microkernel angelegt.

Microkernel sind die kleineren Kernel. Sie versuchen nur grundsätzliche Funktionen direkt durch den Kernel anzubieten. Alles weitere, wie etwa Treiber oder Systemprogramme ist nicht im Kernel sondern wird dynamisch nachgeladen. Aus diesem Grund sind Microkernel auch so „klein“: Bei einer gelungenen Implementierung ist wirklich nur das im Speicher des Computers, was auch gebraucht wird.

Gerade wegen dieses Größenvorteils und vor allem auch wegen der Modularität ist dieses Konzept eigentlich ideal für moderne Computersysteme.

Microkernel haben allerdings auch ihre Schattenseiten. Dadurch, dass Module - Teile des Kernels - eventuell nachgeladen werden müssen wird das ganze System natürlich etwas langsamer. Wenn dazu noch die Implementierung nicht gut gelungen ist, dann kann das Konzept des Microkernels kritische Sicherheitslücken aufweisen.

Exokernel sind wohl die minimalistischsten aller Kernel. In einem Exokernel ist wirklich nur das Notwendigste enthalten. Nicht enthalten sind Funktionen, die über die grundlegensten Aufgaben wie Speicherverwaltung hinausgehen. Idee hinter diesem Konzept ist es, jedem Programm frei zu stellen, wie es mit der Hardware kommunizieren möchte. Treiber und eventuelle Hardwarebibliotheken (z.B. OpenGL oder DirectX) muss das Programm also mitliefern.

Dadurch ist dieses Konzept extrem modular. Jedoch kann diese Modularität zu Konflikten führen, die für das Betriebssystem schwer oder gar nicht zu lösen sind. Denn manche Ressourcen - wie z.B. die komplette Ausgabe, also Grafiktreiber etc. - sollten nur von einem Treiber bedient werden, da sich mehrere geladene Treiber/Module hier gegenseitig stören würden.

Zu der Grafik (rechts) ist anzumerken, dass der hier blau eingefärbte Teil - die Treiber, Module, Bibliotheken - von der Anwendung bestimmt und bereitgestellt werden, nicht vom Kernel.

Das Erste, was ein Kernel können sollte, ist den Speicher verwalten. Das ist wichtig und grundlegend für alle weiteren Aufgaben. Zur Verwaltung des Speichers zählt zum einen die Verwaltung des physikalischen, also wirklich vorhandenen Speichers. Der Kernel muss sich darum kümmern, in welche Bereiche des Speichers Anwendungen Daten schreiben dürfen und in welche nicht. Zusätzlich zum physikalischen Speicher muss der Kernel auch die virtuellen Adressräume verwalten. Jedem Programm wird ein virtueller Adressraum zugeteilt. Da der virtuelle Speicher meist aber viel größer ist als der tatsächlich Vorhandene muss der Kernel festlegen, welche Teile des virtuellen Adressraumes sich wann (und wo) im realen Speicher befinden dürfen.

Neben der Speicherverwaltung muss der Kernel natürlich auch die CPU(s) verwalten. Dazu gehört, dass jedem Prozess eine faire Zeit zugeteilt wird, in der dieser Prozess die CPU für die Erledigung seiner Aufgabe benutzen kann.

An diesen Aufgaben sieht man ganz gut, dass ein Kernel sich eigentlich hauptsächlich um die Verwaltung von Ressourcen kümmern muss. Ob er das nun „im Alleingang“, über geladene Module oder externe Bibliotheken regelt, ist dabei nicht wichtig.