| Zeile 13: | Zeile 13: | ||
* [[Scheduling]] | * [[Scheduling]] | ||
| − | Architekturabhängige Teile dieser Aufgaben werden normalerweise in einem [[Hardware Abstraction Layer]] mit einer klar definierten Schnittstelle gekapselt, um die Wiederverwendbarkeit anderer Komponenten zu erhöhen. Dazu zählen teilweise schon (kleine) Treiber, wie z.B. bei [[x86]] bzw. [[x64]] für die [[PIT]], [[PIC]], [[Local APIC]] oder ähnlichem. | + | Architekturabhängige Teile dieser Aufgaben werden normalerweise in einem [[Hardware Abstraction Layer]] mit einer klar definierten Schnittstelle gekapselt, um die Wiederverwendbarkeit anderer Komponenten zu erhöhen. Dazu zählen teilweise schon (kleine) Treiber, wie z. B. bei [[x86]] bzw. [[x64]] für die [[PIT]], [[PIC]], [[Local APIC]] oder ähnlichem. |
| − | Je nach Kernelart kommt diesen Aufgaben mehr oder weniger Gewicht zu. Außerdem können z.B. folgende Aufgaben hinzukommen: | + | Je nach Kernelart kommt diesen Aufgaben mehr oder weniger Gewicht zu. Außerdem können z. B. folgende Aufgaben hinzukommen: |
* [[Dateisystem]]verwaltung | * [[Dateisystem]]verwaltung | ||
| − | * ausgewählte weitere Treiber (z.B. Treiber zum Erkennen und Konfigurieren von [[PCI]]-Geräten) oder alle Treiber | + | * ausgewählte weitere Treiber (z. B. Treiber zum Erkennen und Konfigurieren von [[PCI]]-Geräten) oder alle Treiber |
== Kernelarten == | == Kernelarten == | ||
| Zeile 24: | Zeile 24: | ||
=== Monolithischer Kernel === | === Monolithischer Kernel === | ||
| − | Als monolithischen Kernel bezeichnet man einen Betriebssystemkernel, der nicht nur die typischen Aufgaben eines solchen durchführt, sondern auch gleich Treiber für alle [[:Kategorie:Hardware | Hardware]], das virtuelle Dateisystem, Dateisystemtreiber und vieles mehr. Diese Treiber können entweder fest in den Kernel einkompiliert sein oder zur Laufzeit ladbar sein, laufen aber immer im Kernelmode. Das Treiberinterface besteht somit aus normalen Funktionsaufrufen, was zu einem deutlichen Geschwindigkeitsvorteil | + | Als monolithischen Kernel bezeichnet man einen Betriebssystemkernel, der nicht nur die typischen Aufgaben eines solchen durchführt, sondern auch gleich Treiber für alle [[:Kategorie:Hardware | Hardware]], das virtuelle Dateisystem, Dateisystemtreiber und vieles mehr enthält. Diese Treiber können entweder fest in den Kernel einkompiliert sein oder zur Laufzeit ladbar sein, laufen aber immer im Kernelmode. Das Treiberinterface besteht somit aus normalen Funktionsaufrufen, was zu einem deutlichen Geschwindigkeitsvorteil führt. Jedoch ist ein solcher Kernel nicht nur unflexibler, sondern auch deutlich fehleranfälliger und abgestürzte Module führen meist zu einem Absturz des gesamten Systems. Interprozesskommunikation spielt in einem solchen Kernel anfangs sicherlich erstmal eine untergeordnete Rolle, da die ges. Funktionalität direkt über den Kernel erreichbar ist. |
Das folgende Diagramm zeigt den groben Aufbau eines monolithischen Kernels: | Das folgende Diagramm zeigt den groben Aufbau eines monolithischen Kernels: | ||
| Zeile 33: | Zeile 33: | ||
=== Mikrokernel === | === Mikrokernel === | ||
| − | Bei einem Mikrokernel im Gegensatz zum monolithischen Kernel | + | Bei einem Mikrokernel liegt im Gegensatz zum monolithischen Kernel nur die Implementierung der oben genannten Basisaufgaben im Kernelspace. [[Treiber]], Dateisystemverwaltung (eventuell inklusive virtuellem Dateisystem) und ähnliche Komponenten liegen als gesonderte Prozesse im Userspace und kommunizieren mit dem Kernel über [[Syscall]]s bzw. mit anderen Prozessen über [[Interprozesskommunikation]]. Der Kernel verwaltet und verteilt also nur die Ressourcen, während die Userspaceprozesse sich um die konkrete Nutzung selbst kümmern. Somit kann ein fehlerhafter [[Treiber]] nicht das ganze [[Betriebssystem]] zum Absturz bringen und eventuell neu gestartet werden. Letzteres funktioniert allerdings nur bei einem entsprechenden Design des Kernels, der Interprozesskommunikation und anderer Komponenten, da z. B. ein abstürzender Festplattentreiber, der die Betriebssystempartition verwaltet, nicht so ohne weiteres nachgeladen werden kann, sondern permanent im Speicher vorgehalten werden muss. |
Prominenter Verfechter dieser Kernelart ist u.a. Andrew S. Tanenbaum, der dieses Prinip in [[Minix]] verwendet. | Prominenter Verfechter dieser Kernelart ist u.a. Andrew S. Tanenbaum, der dieses Prinip in [[Minix]] verwendet. | ||