13.2 Betriebssysteme

Betriebssystem als Vermittler und Ressourcenmanager

Hardware stellt Rechenleistung, Speicher und Ein-/Ausgabefunktionen bereit. Anwendungen sollen diese Komponenten nicht jeweils auf eigene Weise direkt steuern müssen. Das Betriebssystem abstrahiert die konkrete Hardware und bietet beispielsweise Prozesse, Dateien, Netzwerkverbindungen und grafische Ausgaben als nutzbare Konzepte an.

Gleichzeitig verteilt und schützt das Betriebssystem gemeinsam genutzte Ressourcen. Es entscheidet unter anderem, welcher Thread Prozessorzeit erhält, welche Speicherbereiche ein Prozess verwenden darf und welcher Benutzer auf eine Datei zugreifen kann. Damit ist es sowohl erweiterte Maschine als auch Ressourcenmanager.

Kernel, Systemdienste und Benutzeroberfläche

Der Kernel ist der privilegierte Kern des Betriebssystems. Er verwaltet grundlegende Ressourcen und kontrolliert den Zugang zur Hardware. Darüber laufen Systemdienste, Bibliotheken, Kommandozeilen und grafische Oberflächen. Die genaue Grenze hängt vom betrachteten Produkt ab.

Eine Shell oder grafische Oberfläche ist daher nicht pauschal „kein Bestandteil des Betriebssystems“. Sie läuft zwar üblicherweise nicht im Kernelmodus, kann aber zur ausgelieferten Betriebssystemumgebung gehören und deren Bedienoberfläche bilden. Kernel und vollständige Betriebssystemdistribution sind unterschiedliche Betrachtungsebenen.

Benutzermodus und Kernelmodus

Anwendungen laufen normalerweise im Benutzermodus mit eingeschränkten Rechten und voneinander getrennten virtuellen Adressräumen. Für privilegierte Aufgaben rufen sie über definierte Systemaufrufe Dienste des Kernels auf. Ein fehlerhaftes Benutzerprogramm soll dadurch nicht beliebig auf fremden Speicher oder Hardware zugreifen können.

Kernelcode besitzt weitreichende Rechte. Ein Fehler in einem Kernelmodul oder Treiber kann deshalb das gesamte System beeinträchtigen. Der Wechsel zwischen Benutzer- und Kernelmodus erfolgt kontrolliert, etwa durch einen Systemaufruf, einen Interrupt oder eine Ausnahme.

Prozesse, Threads, Scheduler und Dispatcher

Ein Prozess umfasst einen laufenden Programmkontext mit eigenem virtuellen Adressraum und zugeordneten Ressourcen. Ein Thread ist ein ausführbarer Ablauf innerhalb eines Prozesses. Mehrere Threads desselben Prozesses teilen typischerweise Code und Daten, besitzen aber unter anderem eigene Registerzustände und Stacks.

Der Scheduler wählt anhand einer Strategie den nächsten ausführbaren Thread aus. Der Dispatcher setzt die Auswahl technisch um, indem er den Ausführungskontext wechselt. Bei präemptivem Multitasking kann das Betriebssystem einen laufenden Thread unterbrechen; kooperatives Multitasking ist auf freiwillige Abgabe angewiesen. Nebenläufigkeit bedeutet überlappende Fortschritte, Parallelität die tatsächlich gleichzeitige Ausführung auf mehreren Recheneinheiten.

Kommunikation zwischen Prozessen

Getrennte Prozesse benötigen kontrollierte Mechanismen zur Interprozesskommunikation, kurz IPC. Welcher Mechanismus passt, hängt unter anderem von Datenmenge, Richtung, Lebensdauer, Sicherheitsgrenze und der Frage ab, ob die Kommunikation lokal oder über ein Netzwerk erfolgt.

Virtueller Speicher

Virtueller Speicher gibt jedem Prozess einen eigenen logischen Adressraum. Seitentabellen ordnen virtuelle Seiten physischen Speicherrahmen oder anderen Zuständen zu. Das ermöglicht Isolation, Schutzrechte, gemeinsam genutzte Bibliotheken, speicherabgebildete Dateien und bedarfsgesteuertes Laden.

Ist Arbeitsspeicher knapp, kann das Betriebssystem wenig benötigte Seiten verwerfen oder in einen Swap-Bereich auslagern. Bei erneutem Zugriff werden sie wieder eingelesen. Dabei werden nicht pauschal vollständige Prozesse verschoben. Intensive Auslagerung verursacht hohe Latenz und ersetzt keine angemessene RAM-Ausstattung.

Kernelarchitekturen im Vergleich

Der Mikrokernel genauer betrachtet

Ein Mikrokernel beschränkt den privilegierten Kern auf grundlegende Mechanismen wie Scheduling, Interprozesskommunikation, Interruptbehandlung und Teile der Adressraumverwaltung. Dateisysteme, Gerätetreiber oder Netzwerkdienste können als getrennte Prozesse im Benutzermodus ausgeführt werden.

Stürzt ein ausgelagerter Dienst ab, kann er unter geeigneten Bedingungen neu gestartet werden, ohne zwangsläufig den gesamten Kernel zu beenden. Diese Trennung verbessert die Analyse und kann die Vertrauensbasis verkleinern. Sie garantiert jedoch keine Fehlerfreiheit: Abhängigkeiten, IPC, Synchronisation und Wiederherstellung müssen sorgfältig entworfen werden.

Monolithische und modulare Kernel

Bei einem monolithischen Kernel arbeiten zentrale Dienste im selben privilegierten Adressraum. Linux ist ein modular-monolithischer Kernel: Funktionen und Treiber können als Kernelmodule organisiert und häufig zur Laufzeit geladen werden. Dadurch muss nicht jede unterstützte Komponente fest in das Kernelabbild eingebaut sein.

Module verbessern Erweiterbarkeit und Wartbarkeit, stellen aber keine Schutzgrenze wie ein separater Benutzerprozess dar. Fehlerhafter Modulcode kann weiterhin Kernelzustand beschädigen oder einen Systemabsturz auslösen. Linux kann ausgewählte Dateisysteme über FUSE im Benutzermodus betreiben; dies ergänzt die Kernelarchitektur, macht den Kernel aber nicht zum Mikrokernel.

Hybridkernel richtig einordnen

Windows-NT-basierte Systeme und Apples XNU-Kernel werden häufig als Hybridkernel bezeichnet. Sie verbinden unterschiedliche Architekturideen und behalten aus Leistungs-, Kompatibilitäts- oder Produktgründen zahlreiche Dienste im Kernelmodus. Die Einordnung ist eine vereinfachte Beschreibung und kein normiertes Gütesiegel.

Linux: VFS, Dateisysteme und Speicherpfad

Das Virtual File System, kurz VFS, bildet im Linux-Kernel eine gemeinsame Schnittstelle für unterschiedliche Dateisysteme. Ein konkreter Dateisystemtreiber muss die passenden Operationen implementieren. VFS bedeutet daher nicht, dass jedes beliebige Format ohne Unterstützung automatisch gelesen werden kann.

Windows: I/O-Manager, Dateisysteme und Speicherpfad

Eine Windows-Anwendung verwendet normalerweise eine dokumentierte Programmierschnittstelle wie die Win32-API. Beim Öffnen einer Datei entsteht ein Handle auf ein vom Kernel verwaltetes Dateiobjekt. Nach dem Übergang in den Kernelmodus koordiniert der I/O-Manager die Anforderung und leitet sie an die zuständigen Treiber weiter.

Windows verwendet dafür gestapelte Treiber. Ein I/O Request Packet, kurz IRP, enthält die Anforderung und passende Stackpositionen für die beteiligten Treiber. Die Grafik zeigt das Grundprinzip; Cache-Manager, Speicherverwaltung, Sicherheitsprüfung und weitere Komponenten können ebenfalls beteiligt sein.

Linux: Ein gemeinsamer Verzeichnisbaum

Linux ordnet erreichbare Dateisysteme in einen einzigen Verzeichnisbaum mit dem Wurzelverzeichnis / ein. Weitere lokale Datenträger, Netzwerkfreigaben oder virtuelle Dateisysteme werden an Mountpoints eingehängt. Laufwerksbuchstaben wie unter Windows sind dafür nicht erforderlich.

Ein absoluter Pfad beginnt bei /, beispielsweise /home/azubi/notizen.txt. Ein relativer Pfad wird vom aktuellen Arbeitsverzeichnis aus ausgewertet. Dateinamen benötigen unter Linux keine Erweiterung; Erweiterungen bleiben dennoch nützliche Konventionen für Menschen und Anwendungen. Groß- und Kleinschreibung wird von verbreiteten Linux-Dateisystemen unterschieden.

Zusammenfassung

Das Betriebssystem abstrahiert Hardware, verwaltet Ressourcen und schützt Prozesse gegeneinander. Systemaufrufe verbinden Anwendungen im Benutzermodus mit privilegierten Kernelaufgaben. Scheduler, Speicherverwaltung, Treiber, IPC und Dateisysteme bilden zentrale Bausteine.

Mikrokernel, monolithische, modulare und hybride Kernel setzen unterschiedliche Schwerpunkte. Linux verbindet einen modular-monolithischen Kernel mit VFS und einem durch Mounts aufgebauten Verzeichnisbaum. Windows koordiniert Datei- und Gerätezugriffe über den I/O-Manager und geschichtete Treiberstapel; lokale Dateisysteme und SMB-Zugriffe folgen dabei unterschiedlichen Pfaden.