Betriebssystemkerne

Gute Architektur sagt und warum etwas getan wurde.
Nicht wie und nicht wann und wer.

Der Betriebssystemkern

Enthält grundlegende Funktionen des Betriebssystems
- Systemaufrufe
- Benutzerverwaltung
- Prozessverwaltung inklusive Ausführungsreihenfolge (Scheduling)
- Interprozesskommunikation
- Prozessumschalter (Dispatcher)
- Gerätetreiber
- Speicherverwaltung
- Dateisysteme zur Verwaltung von Dateien auf Speicherlaufwerken
Ist die Schnittstelle zur Hardware des Computers
- Funktionalitäten im BS-Kern haben vollen Hardwarezugriff
- Funktionalitäten laufen als Prozess im Adressraum des Kerns
- Funktionalitäten müssen nicht zwingend im Kern positioniert sein, sie können auch über Dienste bereitgestellt werden (Architektur)

Der User-Bereich ist nicht privilegiert, kann aber darauf aufbauende Funktionalitäten bereitstellen
Zugriff auf die Hardware erfolgt alleinig durch die im Kernel bereitgestellten Funktionalitäten (System-Calls)

Ein Monolith enthält alle Funktionalitäten eines Betriebssystems

Pro	Con
Bessere Ausführungsgeschwindigkeit da weniger Prozesswechsel notwendig sind	Abgestürzte Komponenten des Kerns können nicht separat neu gestartet werden -> können das gesamte BS zum Absturz bringen
Durch jahrelange Entwicklungstätigkeit ist eine gewachsene Stabilität vorhanden

Hier befinden sich nur die nötigsten Funktionen im Kernel

Pro	Con
Alle weiteren Funktionalitäten laufen als Dienste bzw. Server im User-Modus	Abgestürzte Komponenten des Kerns können nicht separat neu gestartet werden -> können das gesamte BS zum Absturz bringen
Ausgelagerte Funktionalitäten sind leichter austauschbar, bietet bessere Stabilität und Sicherheit

Enthalten Komponenten, die, aus Geschwindigkeitsgründen, zusätzlich in den Kernel aufgenommen werden

Pro	Con
höhere Geschwindigkeit als minimale Kerne	keine klare Definition, was in den Kernel integiert wird
höhere Stabilität als monolithische Kerne	Systeme differieren stark -> kann zu einer fehlenden Unterstützung der Hardware- und Software-Hersteller führen

Flaschenhals alle bestehenden Systeme liegt in ihren Schichtenmodellen

Anwendung hat keinen direkten Zugriff auf Hardware
Kommunikation und Datenfluss wird über Bibliotheken und deren Kernel abgewickelt
Zugangskontrolle weiterhin über Bibliotheken und Kernel

Systemaufruf (System Call) ist eine API, die es ermöglicht auf Dienste und Ressourcen des BS zuzugreifen

Implementierung von Systemaufrufen hängt stark von Hardware, Architektur, BS ab
Wann werden die benutzt?
- Berechtigungen, Ressourcenverwaltung, Kommunikation mit Hardware, Prozesssteuerung, Netzwerkkommunikation, Zeitverwaltung
Nutzung eines direkten Systemaufrufs nicht empfehlenswert
- Software ist schlecht portierbar
- Auf Funktionen von Bibliotheken zurückgreifen
  - befinden sich mit entsprechenden Wrapper-Funktionen logisch zwischen Benutzer- und BS-Kern