Kapitel 1 Grundlagen - Rechensysteme PDF

Kapitel 1 Grundlagen 1.1 Rechensysteme 1.1.1 Definition Allgemein betrachtet ist die Aufgabe der Informatik, Rechensysteme zu entwickeln und diese Anwendern als leistungsfähige Hilfsmittel für Lösungen ihrer Informa- tionsverarbeitungsprobleme zur Verfügung zu stellen. Statt dem Begriff Rech...

Kapitel 1 Grundlagen 1.1 Rechensysteme 1.1.1 Definition Allgemein betrachtet ist die Aufgabe der Informatik, Rechensysteme zu entwickeln und diese Anwendern als leistungsfähige Hilfsmittel für Lösungen ihrer Informa- tionsverarbeitungsprobleme zur Verfügung zu stellen. Statt dem Begriff Rechen- system wird häufig auch «Rechner» oder «Computer» verwendet. Ein Rechensystem lässt sich verallgemeinern als ein offenes, dynamisches und technisches System mit den Fähigkeiten Informationen zu speichern und zu verarbeiten sowie zu kommunizieren. Die Begriffe offen, dynamisch und technisch lassen sich wie folgt erklären: Offenes System Ein offenes System zeichnet sich dadurch aus, dass es sich in voneinander ab- hängige Komponenten gliedern lässt. Die Abhängigkeiten werden mittels Schnitt- stellen realisiert: Diese regeln und dokumentieren die Kommunikation zwischen 10 den einzelnen Komponenten. Ein Beispiel für eine Schnittstelle innerhalb eines Rechensystems wäre eine Netzwerkschnittstelle, die den restlichen Komponen- ten den Zugriff auf ein Computernetzwerk ermöglicht. Alle Peripheriegeräte wie Tastatur, Maus und Bildschirm kann man als Schnittstelle nach außen, zum Be- nutzer, betrachten. Schnittstellen ermöglichen zwei verschiedene Sichten auf eine Komponente: 1. Von außen wird ein Teilsystem als eine Black-Box betrachtet. Das Verhalten des Systems ist bekannt, jedoch nicht die interne Funktionsweise. 2. Im Gegensatz dazu steht die White-Box-Sicht: Man kann ein System rekur- siv in Teilsysteme verfeinern, bis die genaue Funktionsweise bekannt ist (vgl. Abbildung 1.1) White BlackBox Box Abbildung 1.1: Black-Box- und White-Box-Sicht Dynamisches und technisches System Ein dynamisches System befindet sich zu einem Betrachtungszeitpunkt in einem Zustand, der durch eine Reihe von Eigenschaften beschrieben werden kann. Die- ser Zustand ändert sich über die Zeit. Eine Folge von Zustandsänderungen be- schreibt das Systemverhalten. Ein Rechensystem erhält diese Fähigkeit zur Zu- standsänderung dadurch, dass es aus aktiven und passiven Komponenten be- steht: 11  Aktive Komponenten führen Aktionen aus, die Zustandsveränderungen auslösen. Ein Beispiel für eine aktive Komponente ist die CPU. Passive Komponenten sind Hilfsmittel für diese Aktionen. Ein Beispiel hier- für ist der Arbeitsspeicher des Rechensystems. Schließlich ist ein System ein technisches System, wenn es mittels hardware- und softwaretechnischen Mitteln realisiert wurde. 1.1.2 Struktur von Rechensystemen Rechnerarchitektur Nachdem der Begriff des Rechensystems geklärt ist, soll ein Blick auf die grobe Architektur eines solchen geworfen werden. Ein bekanntes Beispiel hierfür ist die Von-Neumann-Architektur: Rechenwerk CPU Steuerwerk Bus-System Ein-/Ausgabewerk Speicherwerk Abbildung 1.2: Von-Neumann-Architektur Dabei enthält der Prozessor ein Rechenwerk und ein Steuerwerk. Er ist über einen Bus mit einem Speicher verbunden, der sowohl Instruktionen als auch Daten ent- hält. Außerdem gibt es Mechanismen zur Ein- und Ausgabe von Daten. Ein ver- gleichsweise einfaches, reales Beispiel für solch eine Architektur wäre ein Raspber- ry Pi 3. 12  (a) Aussehen (b) Schema Abbildung 1.3: Ein Raspberry Pi 3B Schichtenstruktur eines Rechensystems Wie aus der Abbildung 1.3 ersichtlich ist, gibt es in einem realen Rechensystem verschiedenste Hardwarekomponenten und Schnittstellen. Die Hardware findet sich in der untersten Schicht einer Schichtenstruktur (Siehe Abbildung 1.4) wie- der, die als Modellierung des Rechensystems dient: Word, Excel, World Wide Web Anwendungsprogramme Shell, Compiler, Dateisysteme Systemprogramme Betriebssystem Maschinensprache Mikroprogramme / festverdrahtete Programme Hardware physische Komponenten und Geräte Abbildung 1.4: Schichtenstruktur Die oberste Ebene bilden die Anwendungsprogramme. Diese könnten beispiels- weise ein Textverarbeitungsprogramm oder ein Webbrowser sein. Die Schichten 13 darunter abstrahieren schrittweise die Details des Rechensystems, mit dem Zweck die Programmierung zu vereinfachen. Das Betriebssystem realisiert genau diese Abstraktion und bietet daher für An- wendungsprogramme vereinheitlichte Schnittstellen zur Hardware an. Die ein- zelnen Komponenten des Rechensystems (Bildschirm, Festplatte, Arbeitsspeicher, Tastatur, etc.) werden als Ressourcen betrachtet, da diese nur begrenzt vorhanden sind und verwaltet werden müssen. 1.2 Betriebssysteme: Allgemeines Definition Die DIN 44300 (1972) definiert ein Betriebssystem nach dessen Aufgabe und Stel- lung gegenüber Anwendungsprogrammen: Das Betriebssystem wird gebildet durch die Programme eines digitalen Re- chensystems, die zusammen mit den Eigenschaften der Rechenanlage die Grund- lage der möglichen Betriebsarten des digitalen Rechensystems bilden und ins- besondere die Ausführung von Programmen steuern und überwachen. Eine alternative Definition lautet wie folgt: Das Betriebssystem ist ein Programm, das die Ausführung von System- oder Anwendungsprogrammen steuert und überwacht und für die Anwen- dungsprogramme eine Schnittstelle zu den Hardware-Komponenten bereit- stellt. Aufgaben Diese Definitionen leiten sich aus den zwei zentralen Aufgaben eines Betriebssy- stems ab: 1. Abstraktion. Das Ziel der Vereinfachungen ist, mittels abstrakten Konzep- ten gemeinsame Schnittstellen zu schaffen. Ein Beispiel hierfür sei der Zu- griff auf Ein-/Ausgabe-Geräte: Jedes Gerät hat seinen eigenen Befehlssatz. 14  Ohne Abstraktion müsste jedes Anwendungsprogramm das Verhalten ei- nes jeden Geräts kennen. Die Lösung dafür ist, dass das Betriebssystem ei- ne einheitliche Schnittstelle anbietet. Das Anwendungsprogramm verwen- det diese Operationen, das Betriebssystem setzt diese dann auf die Geräte- spezifischen Befehle um. Dabei verwendet es einen «Treiber»1 , ein Pro- Kirill : gramm, das die Details des Gerätes kennt und implementiert. Link auf Treiber 2. Ressourcenmanagement. Das Betriebssystem verwaltet verschiedene Res- sourcen. Üblicherweise werden mehrere Programme «gleichzeitig» ausge- führt. Der Zugriff auf eine Ressource, wie etwa einen Drucker muss also kontrolliert werden, damit zwei Programme, die den Drucker verwenden, sich nicht gegenseitig behindern können. Dies kann durch das Betriebssy- stem z.B. über die Dauer und den Zeitpunkt der Ausführung der Anwen- dungsprogramme steuern. Hierbei muss das Betriebssystem strategische Ent- scheidungen treffen: Welches Programm wird priorisiert? Ist die Ressour- cenaufteilung fair? Wie adaptiv ist der Entscheidungsmechanismus bei spon- tanen Anforderungen? Faktoren für die Entwicklung von Betriebssystemen Betriebssysteme haben sich im Laufe der Zeit stark gewandelt, und bis heute wird laufend an ihnen weiterentwickelt. Dass die Entwicklung vorangetrieben wird, liegt mehreren Faktoren zugrunde: Fortschritte der Hardwaretechnologie: So wie sich die Leistung der Hard- ware entwickelt, steigen auch die Anforderungen der Benutzer. Wird ein Rechensystem beispielsweise mit einer schnelleren Festplatte ausgerüstet, dann wird erwartet, dass das Betriebssystem in der Lage ist diese neue Ge- schwindigkeit vollständig auszunutzen. Übergang von rein numerischer Berechnung zur allgemeinen Informati- onsverarbeitung: Nachdem mit der Zeit Rechensysteme für Konsumenten zugänglich wurden, müssen diese nun auch eine Nutzung durch Nicht- Spezialisten ermöglichen, z.B. mittels grafischen Benutzeroberflächen und einem interaktiven Betrieb. 1 Siehe Kapitel 8: Ein-/Ausgabe 15  Neue Anwendungsbereiche und Digitalisierung: Es kommen stets neue Technologien auf den Markt, die vom Betriebssystem zugänglich gemacht werden sollen. Letzte Änderungen beinhalten z.B. die vermehrte Nutzung von Clouds und eingebetteten Systemen in Autos sowie die Einbindung von IoT-Geräten (Internet of Things) in den Alltag. Einsatzgebiete für Betriebssysteme Die Einsatzgebiete für Betriebssysteme lassen sich wie folgt kategorisieren: Server-Betriebssysteme: Diese sind rein für den Einsatz auf Rechen- und Datenzentren konzipiert, z.B. SuperMUC, MPI. Server- und Desktop-Betriebssysteme: Diese zielen auf Endnutzer ab und sind auch für kleine bis mittelgroße Server geeignet. Beispiele: Linux, Win- dows, macOS Mobile Betriebssysteme: Gedacht für den Einsatz auf Smartphones sind Android, iOS, etc. Eingebettete Betriebssysteme: Diese werden für Mikroprozessoren entwickelt. Beispiele: QNX, L4 (embedded), PikeOS, TinyOS, RTOS, RIOT Ziele bei der Entwicklung von Betriebssystemen Je nach Einsatzgebiet werden bei der Entwicklung unterschiedliche Ziele verfolgt. Zunächst stellt sich die Frage nach dem Zweck des Betriebssystems. Dabei kann man grob zwei Arten unterscheiden: 1. General Purpose: Diese Systeme sollen für allgemeine Probleme ge- eignet sein und sind daher sehr umfangreich und komplex. Beispiele hierfür sind Desktop-Betriebssysteme wie macOS, Windows oder Li- nux, aber auch mobile Betriebssysteme wie Android oder iOS. 2. Special Purpose: Diese haben eine eingeschränkte Funktionalität, sind jedoch einfacher und bei Bedarf auch verifizierbar. Danach folgen die genaueren Ziele. Dabei müssen in der Regel Kompro- misse eingegangen werden, da nicht alle Ziele gleichzeitig erreichbar sind. Beispiele für Ziele in ihren typischen Einsatzgebieten sind: 16  – Hohe Auslastung. (Server und Datenzentren) – Kurze Antwortzeiten. (Server-/ Desktop-Systeme, Eingebettete Syste- me) – Geringer Energieverbrauch. (Eingebettete Systeme, Mobile Systeme) – (usw...) Betriebsarten Aus den Einsatzgebieten heraus ergeben sich für ein Betriebssystem verschiede- ne Betriebsarten. Diese beeinflussen u.A. Entscheidungen über Ressourcenverga- ben2 , die das Betriebssystem treffen muss. 1. Stapelbetrieb (Batch-Systeme). Alle Programme sind vor dem Start kom- plett definiert. Während diese Liste/Stapel von Programmen abgearbeitet wird, ist keine Nutzerinteraktion vorgesehen. Diese Betriebsart war bei frü- hen Rechenanlagen weit verbreitet (Historische Entwicklung). 2. Dialogbetrieb (Interaktive Systeme). Diese Betriebssysteme erlauben dem Nutzer mit dem Rechner über eine Benutzerschnittstelle wie z.B. einem Desktop zu interagieren. Diese Systeme entsprechen den geläufigen Betriebssyste- men für Endnutzer wie Windows, Linux, usw. 3. Transaktionsbetrieb (Transaktionssysteme). Ist auch bekannt aus dem Be- reich der Datenbanken. Erfüllt ACID-Kriterien (Atomarität, Konsistenz, Iso- lation, Dauerhaftigkeit) 4. Echtzeitbetrieb (Echtzeitsysteme). Hier spielt die Reaktionszeit des Betriebs- systems eine zentrale Rolle. Diese Betriebsart wird insbesondere in die Ro- botik und bei eingebetteten Systemen verwendet. Für Aktionen kann es fol- gende Deadlines geben, vor deren Ablauf die Aktion fertig ausgeführt sein muss: Hard Deadlines: Die Reaktionszeit darf keinesfalls überschritten wer- den. Andernfalls würde ein gravierender Fehler auftreten. Ein Airbag muss bei einem Unfall beispielsweise auslösen bevor der Insasse ein- schlägt. Ein Roboter muss rechtzeitig eine Notbremsung einleiten, wenn er auf ein Hindernis zusteuert. 2 Siehe Kapitel 2: Scheduling-Algorithmen 17  Soft Deadlines: Gewisse Toleranzen sind erlaubt. Sollte die Deadline nicht eingehalten werden, tritt kein gravierender Fehler auf. Wird z.B. beim Abspielen eines Videos ein Abschnitt nicht schnell genug geladen, so verzögert sich die Wiedergabe. Historische Entwicklung Die historische Entwicklung von Betriebssystemen kann man grob in fünf Gene- rationen zusammenfassen: 1. Generation (1945-1955): Hier wurde an Rechenanlagen gearbeitet, die noch kein Betriebssystem verwendeten, z.B. die Zuse Z3. 2. Generation (1955-1965): Rechner aus dieser Zeit arbeiteten im Stapelbetrieb, ohne parallele Verarbeitung. Der Begriff «Stapelverarbeitung» stammt aus genau dieser Zeit, da Programme und Daten in Form von Lochkarten vor- lagen und stapelweise abgearbeitet wurden. Ein Beispiel für einen Rechner aus dieser Zeit ist der TR4. 3. Generation (1965-1980): Nun gibt es Betriebssysteme, die mehrere Program- me ausführen können, ein Dialogbetrieb ist möglich, Aufträge können auf Speicherplatten temporär ausgelagert werden, bis Ressourcen verfügbar sind («spooling») und es entstehen erste Dateisysteme. Aus dieser Zeit sind Be- triebssysteme wie Multics und Unix hervorgegangen. 4. Generation (ab 1980): Zu dieser Zeit sind die ersten Versionen von Betriebs- systemen wie Windows, MacOS und Linux entstanden. Es gibt erste Rechner für Privatpersonen, erste graphische Benutzeroberflächen, Computer wer- den untereinander vernetzt und um Multimedia-Funktionen erweitert. 5. Generation (ab 2000): Mobile Betriebssysteme wie Android und iOS entste- hen. Auch eingebettete Systeme und Chipkarten werden nun von Betriebs- systemen gesteuert. 1.3 Betriebssysteme: Grundlegende Konzepte Es soll nun ein Überblick über einige wichtige Konzepte gegeben werden, um sie die in den folgenden Kapiteln zu vertiefen. 18 1.3.1 Klassifikation von Ressourcen Bei den Ressourcen, die ein Betriebssystem verwaltet, handelt es sich größtenteils um physische Komponenten, wie etwa einen Drucker oder die Rechenzeit der CPU. Es sei jedoch am Rande angemerkt, dass es auch virtuelle Ressourcen gibt, wie etwa Signale oder Nachrichten3. Im Allgemeinen lassen sich den Ressourcen verschiedene Eigenschaften zuschreiben: Anzahl der Nutzungen Viele Ressourcen können mehrmals verwendet werden, wie die CPU oder der Speicher. Es gibt jedoch auch Ressourcen, die nur einmal benutzt werden können. Beispiel: eine leere CD kann genau einmal beschrieben werden. Parallelität Bei der parallelen Nutzbarkeit einer Ressource gibt es mehrere Abstufungen. Zu- nächst gibt es uneingeschränkt parallel nutzbare Geräte, wie etwa eine Festplatte im lesenden Modus. Daneben gibt es beschränkt parallel nutzbare Ressourcen, wie eine Festplatte im schreibenden Modus. Zuletzt gibt es noch Ressourcen, die ausschließlich exklusiv nutzbar sind, z.B. der Drucker. Unterbrechbarkeit Hierbei geht es darum, ob die Funktion, die das Gerät oder die man mit dem Gerät ausführt, unterbrechbar ist oder nicht. Unterbrechbar ist z.B. das Lesen einer Festplatte. Der Druckvorgang eines Druckers oder das Schreiben einer CD-ROM kann jedoch nicht unterbrochen werden. Zentrale vs. periphere Ressourcen Als zentrale Ressourcen werden jene betrachtet, die für den Betrieb des Rechners unerlässlich sind, wie etwa Prozessoren und der Arbeitsspeicher. Als periphere Ressourcen werden hingegen jene bezeichnet, die eine Ein-/Ausgabe-Funktion haben, wie Tastatur oder Bildschirm, aber auch Festplatten, Netzwerkkarten oder Scanner. 3 Siehe Kapitel 5, Prozesskommunikation 19 Weitere Unterscheidungsmerkmale Weiters kann man auch aktive und passive Ressourcen unterscheiden, wie in Ab- schnitt 1.1.1 beschrieben. Zwar sind zahlreiche Ressourcen in Hardware realisiert, jedoch gibt es auch welche, die in Software implementiert sind. Somit lassen sich Ressourcen auch nach diesem Merkmal unterscheiden. Je nach Fragestellung las- sen sich auch noch weitere Eigenschaften von Ressourcen finden. 1.3.2 Prozesse Programme und Prozesse Bekanntlich ist ein Programm eine Folge von Maschinenbefehlen, die in der Regel in Form eines binären Maschinencodes vorliegt. Ein Programm ist jedoch passiv: Der Maschinencode ist lediglich eine Beschreibung der Befehlsfolge und wird als Datei auf einem Datenträger abgespeichert. Ein Prozess hingegen ist ein in Ausführung befindliches Programm. Er ist eine aktive Einheit, die einen Zustand besitzt und Daten auf dem Rechensystem ver- arbeitet. Ein Prozess wird auch als Instanz eines Programmes bezeichnet. Dabei kann es in einem System mehrere Instanzen des gleichen Programmes geben, bei- spielsweise zwei Instanzen des vim Texteditors. Ressourcenverteilung unter Prozessen Ein Rechensystem besteht aus einer Menge von Prozessen, die sich begrenzte Res- sourcen, insbesondere Arbeitsspeicher und Rechenkerne, teilen müssen. Um Interferenzen zwischen Prozessen zu vermeiden, werden sie voneinander iso- liert. Aus der Sicht eines einzelnen Prozesses hat dieser dann seine eigene CPU und seinen eigenen Speicher und bekommt, wenn nicht anders erwünscht, von allen anderen Prozessen nichts mit. Die konkrete Ressourcenvergabe ist Aufgabe des Betriebssystems: Im Fall des Prozessors wird von der Prozessorverwaltung gesprochen. In- dem das Betriebssystem die Prozesse abwechselnd die CPU(s) für einen ge- wissen Zeitraum nutzen lässt, kann es auf einem Rechensysteme mehr Pro- zesse als Rechenkerne geben. Die zeitliche Trennung der CPU-Nutzung trägt 20  zur Isolation der Prozesse bei. Wird das Zeitintervall, nachdem gewechselt wird kurz genug gewählt, entsteht ein Eindruck von Parallelität. Im Fall des Arbeitsspeichers wird von der Speicherverwaltung gesprochen. Dabei bekommt jeder Prozess einen eigenen Prozessadressraum, der den Maschinencode des Prozesses sowie dessen Daten enthält. Die Adressräu- me mehrerer Prozesse befinden sich gleichzeitig im Speicher, sie werden in diesem Fall also nicht zeitlich voneinander getrennt. Die Trennung erfolgt stattdessen mittels dem Konzept des «virtuellen Adressraumes»: Dies ist ei- ne Abstraktion des physischen Arbeitsspeichers, die mit der Hilfe von spe- zieller Hardware dem Betriebssystem das Isolieren der Prozessadressräume ermöglicht. Weiter nutzt ein Prozess Ein- und Ausgabegeräte sowie Dateien. Auch den Zugriff auf diese muss das Betriebssystem verwalten, um ungewollte Wech- selwirkungen zwischen Prozessen zu vermeiden. 0xFFFF 0xFFFF Stack Stack P1 P2 Daten Daten Code Code 0x0000 0x0000 Abbildung 1.5: Prozessadressräume 1.3.3 Datei- und Gerätezugriff Bekanntlich werden Dateien auf einer Festplatte mit einer Baumstruktur organi- siert, die einen gezielten Zugriff auf eine bestimmte Datei ermöglicht. 21 Everything is a file Das Betriebssystem soll Programmen jedoch nicht nur Zugang zu Dateien in dei- nem Dateisystem auf einer Festplatte, sondern auch zu allen anderen Geräten (Maus, Tastatur, Drucker, CD-Laufwerk, uvm.) ermöglichen. Dafür hat sich der Ansatz von Gerätedateien durchgesetzt: Eine Gerätedatei ist dabei eine spezielle Datei, die ein beliebiges Ein- und/oder Ausgabe-Gerät repräsentiert. Diese Gerä- tedatei befindet sich (wie alle anderen Dateien auch) im Verzeichnisbaum, jedoch existiert sie nicht auf einer Festplatte. Unter Unix (Heutzutage meist Linux, aber genauso auch macOS) gibt es das Prin- zip Everything is a file. Das bedeutet, dass sämtliche Geräte, Dateien oder Kom- munikationsmittel, die das Rechensystem hat, durch eine Datei im Verzeichnis- baum zugreifbar ist. Der Verzeichnisbaum ist also nicht nur Schnittstelle zu Da- teien der Festplatte, sondern auch zu allen anderen Geräten/Objekten, die in ir- gendeiner Form Ein- und/oder Ausgabe können. Dieses Prinzip wurde eingeführt, um eine einheitliche Schnittstelle für die Pro- gramme zu schaffen. Aus der Sicht eines Anwendungsprogrammes macht es dann zum Beispiel beinahe keinen Unterschied mehr, ob eine eingelesene Zeile aus ei- ner Netzwerkverbindung, aus einer Datei von Festplatte, oder von einem Termi- nal kommt. Die Unterscheidung, welches Gerät hinter einer Datei steckt, imple- mentiert das Betriebssystem unter der Verwendung von Treibern. Dateideskriptoren Programmatisch erfolgt der Zugriff auf eine beliebige Datei im Verzeichnisbaum über einen sogenannten Dateideskriptor (engl. file descriptor, oft mit fd abge- kürzt). Ein Dateideskriptor ist aus der Sicht des Programmes ein einfacher int-Wert, der eine offene Datei referenziert. Wegen dem «everything is a file»-Prinzip kann die- ser Dateideskriptor sowohl eine normale Datei, als auch z.B. einen Endpunkt einer Netzwerk- oder Prozesskommunikation4 referenzieren. Mittels Funktionen aus der Standardbibliothek, wie z.B. open(), read(), write() und close(), kann dann 4 sog. Socket bzw. Pipe, siehe auch Kapitel 5: Prozesskommunikation 22 der Dateideskriptor zum Lesen und Schreiben von Daten verwendet werden. Das Betriebssystem verwendet die Dateideskriptoren für die Verwaltung der ge- öffneten Dateien und für die praktische Umsetzung der gewünschten Lese- und Schreiboperationen. 1.3.4 Betriebssystem-Modi Um das Betriebssystem vor Programmfehlern und Angriffen zu schützen, sowie unkontrollierte Ressourcenzugriffe zu verhindern, gibt es üblicherweise zwei Ar- beitsmodi mit unterschiedlichen Berechtigungen. Diese werden von der Hardwa- re (insb. vom Prozessor) implementiert und ermöglichen die strikte Trennung des Betriebssystems von den Anwendungsprogrammen: 1. Benutzermodus (User Mode): In diesem Arbeitsmodus werden Anwendungs- programme ausgeführt. Es ist kein direkter Hardware-Zugriff möglich und privilegierte Maschinenbefehle wie z.B. hlt sind nicht gestattet. Der Spei- cherzugriff ist auf einen einzigen Prozessadressraum eingeschränkt. 2. Systemmodus (Kernel Mode): Dieser Arbeitsmodus ist für das Betriebssy- stem bestimmt und erlaubt freien Zugriff auf die Hardware, sowie die Aus- führung von privilegierten Maschinenbefehlen. Es darf auf den gesamten Speicher zugegriffen werden. Man kann nicht verallgemeinern, dass das Betriebssystem ausschließlich im Sy- stemmodus läuft. Es sind lediglich die zentralen Bestandteile, die zusammenge- fasst Kernel genannt werden, die auch im «Kernel Mode» ausgeführt werden müssen. Die restlichen Funktionen können auch im User Mode ausgeführt wer- den. Ob das geschieht, hängt von der Architektur des Betriebssystems ab. 1.3.5 Systemaufrufe Damit die Anwendungsprogramme Zugriff auf Funktionen des Betriebssystems und auf die Hardware erhalten können, stellt das Betriebssystem eine Reihe von Systemaufrufen (engl.: system call) als Schnittstelle zur Verfügung. Die Implementierung dieser Dienste erfordert in der Regel, dass sich das System im Kernel Mode befindet. Daher muss ein Systemaufruf einen Wechsel vom User 23 Mode in den Kernel Mode einleiten. Das ist mit einem normalen Funktionsaufruf nicht möglich, daher werden Systemaufrufe mittels einem Interrupt ausgelöst, der die Kontrolle an das Betriebssystem abgibt und gleichzeitig in den Kernel Mode wechselt. Da dies Detailkenntnisse über das System sowie Assembler-Kenntnisse erfordert, werden Systemaufrufe typischerweise nicht direkt in Anwendungen verwendet. Stattdessen erfolgt der Aufruf indirekt über Systembibliotheken wie etwa libc. Beispiele für Systemaufrufe unter Linux wären z.B. sys_open, sys_read, sys_write und sys_close. Für diese Systemaufrufe gibt es in der C-Standardbibliothek die entsprechenden Funktionen open, read, write und close, die kaum mehr tätigen, als den Systemaufruf weiter zu geben (sog. «Wrapper»). Andere Bibliotheksfunktionen verwenden diese Funktionen ebenso. Zum Beispiel formatiert die Ausgabefunktion printf in C zunächst den Text, und wird an- schließend eine write-Funktion für das eigentliche Schreiben des erzeugten Textes verwenden. Dieses Fallbeispiel soll nun genauer betrachtet werden: 1. Für den Aufruf von printf werden die Parameter (z.B. "Wert=%d\n" und 5) auf den Stack gepusht. 2. Mittels call ruft das Anwendungsprogramm die Bibliotheksfunktion printf5 auf. 3. Die Implementierung von printf formatiert den Text nach dem angegebe- nen Schema. Dabei ist das System weiterhin im Benutzermodus. 4. Nun bereitet die Bibliotheksfunktion den eigentlichen Systemaufruf vor. Da- für werden die Nummer des Systemaufrufs, sowie dessen Parameter (In die- sem Fall der Dateideskriptor von stdout6 , ein Zeiger auf den Text, sowie die Länge des Textes) in Register abgelegt. 5. Der Systemaufruf geschieht, indem ein Interrupt ausgelöst wird, welcher die Kontrolle an das Betriebssystem gibt. Das System wechselt dabei in den Systemmodus. 6. Das Betriebssystem erkennt anhand der Werte in den Registern, welcher Sy- stemaufruf angefordert wird, und überprüft, ob dieser zulässig ist. 7. Nun wird das eigentliche Schreiben des Textes in die Standardausgabe aus- geführt. 5 Bestandteil der Standard Bibliothek in C für Ein- und Ausgaben: stdio 6 Standardausgabe 24  Benutzermodus Systemmodus Anwendungsprogramm printf-Implementierung Betriebssystem Bereite Aufruf von printf vor rufe printf auf Formatieren des Textes Systemaufruf vorbereiten löse Interrupt aus Prüfen ob der Aufruf gültig ist Systemaufruf ausführen Zur Bibliotheksfunktion zurückkehren Fortsetzung des Programmes Abbildung 1.6: Ablauf eines Systemaufrufs 8. Das Betriebssystem kehrt von der Interruptbehandlung zurück, die Kontrol- le wird an die printf-Funktion übertragen, und das System wechselt wieder in den Benutzermodus. 9. Die printf-Funktion gibt die Kontrolle an das Anwendungsprogramm wei- ter, welches nun fortgesetzt werden kann. 1.3.6 Betriebssystemarchitekturen Im Laufe der Zeit haben sich unterschiedliche Architekturen für Betriebssysteme entwickelt. Dabei sind neben geschichteten Systemen und Client-Server-Modellen 25 insbesondere monolithische Systeme und Mikrokernel-Systeme weit verbreitet. Monolithisches System Ein monolithisches System zeichnet sich dadurch aus, dass das Betriebssystem als große Sammlung zahlreicher Funktionen implementiert wird. Diese werden in einem umfangreichen Kernel zusammengefasst. Auch alle Treiber sind inner- halb des Kernels implementiert. Das Betriebssystem wird dann als ein großes Pro- gramm ausgeführt. Der Umfang z.B. von Linux 4.1 beträgt mehr als 20 Millionen Codezeilen. Eigenschaften von monolithischen Systemen: Das Betriebssystem läuft vollständig im Kernel Mode. Der Kernel hat eine hohe Ablaufpriorität, d.h. er kann nicht unterbrochen werden. Vorteil von monolithischen Systemen: Ein monolithischer Kernel kann sehr flexibel programmiert werden. Nachteile von monolithischen Systemen: Da sie nur eine minimale Struktur aufweisen und sehr groß werden können, sind sie schnell unübersichtlich. Monolithische Kernel sind weniger resilient/widerstandsfähig, da ein Feh- ler in einer Prozedur zum Absturz des gesamten Programmes führt. Um diesen Nachteilen entgegen zu wirken, werden monolithische Kernel auch variiert, indem sie z.B. modularisiert und um eine Schichten- oder Ringstruktur ergänzt werden. Eine gewisse Modularität ist auch erforderlich, damit das Be- triebssystem auf eine andere Hardware exportiert werden kann. Mikrokernel Mit einem monolithischen Kernel haben Bugs, wegen der schieren Größe des Ker- nelcodes, weitreichende Auswirkungen, was für viele Anwendungsbereiche nicht akzeptabel ist. Daher gibt es den Ansatz der Mikrokernel-Architektur. Hier wird das Betriebssystem in mehrere kleinere Module, sowie einen Mikrokernel aufge- teilt. Diese Module laufen nicht als ein großes Programm, sondern in Form von 26 mehreren, eigenständigen Systemprozessen. Alle, bis auf der Mikrokernel selbst, laufen dabei im User Mode. Beispiele für solche Systeme sind MINIX, PikeOS, QNX, uvm. Eigenschaften von Mikrokernel-Architekturen: Der Mikrokernel bietet nur noch Basismechanismen, wie Scheduling oder Speicherverwaltung an. Er ist das einzige Subsystem, das im Kernel Mode ausgeführt wird. Die restlichen Subsysteme sind Systemdienste im User Mode, d.h. sie haben keine zusätzlichen Privilegien. Sie werden als Serverprozesse ausgeführt nach dem Client-Server-Modell. Solche Server sind dann z.B. der Dateiser- ver oder die Prozessverwaltung. Vorteile von Mikrokernel-Architekturen: Sie sind leichter wartbar: Bugs können in kleineren Abschnitten besser ge- funden werden. Sie sind sicherer, da viele Teile des Betriebssystems nicht mehr Berechtigun- gen haben, wie normale Anwendungsprogramme. Sie sind ggf. verifizierbar, da der Kernel überschaubar groß ist. Die Korrekt- heit von einzelnen kleineren Subsystemen kann leichter bestimmt werden als von einem großen System. Sie sind modularer, Subsysteme können ausgetauscht werden. Nachteile von Mikrokernel-Architekturen: Durch häufigere Wechsel des Arbeitsmodus wird die Performanz beein- trächtigt. Da die Subsysteme strenger voneinander getrennt sind, entsteht ein Kom- munikationsoverhead. Hybride Varianten und Überblick In der Praxis begegnet man auch gemischten Varianten, sogenannte hybride Ker- nel. Während der MS DOS-Kernel (Basis für frühe Windows-Versionen) monoli- thisch war, ist der Windows NT-Kernel (Basis seit 1993 bis hin zu den aktuellen Windows-Versionen) hybrid. 27  Abbildung 1.7: Übersicht über Kernelarchitekturen 1.3.7 Systemprogrammierung Die Systemprogrammierung befasst sich mit der Konstruktion von Algorithmen für ein Rechensystem, die die Bearbeitung und Ausführung von Benutzerpro- grammen unter vorgegebenen Qualitätsgesichtspunkten organisieren, d.h. steu- ern und kontrollieren und zum Teil selbst durchführen. Unter System-Software versteht man Programme, die Dienste für Anwendungs- programme anbieten. Diese müssen häufig sehr hardwarenah programmiert wer- den, d.h. mit Assembler, C oder C++. Sie müssen, um nicht Ressourcen von An- wendungsprogrammen zu verbrauchen, auf eine effiziente Ausführung optimiert sein. Unter System-Software fallen Programme wie Kernel, Treiber, Compiler, Lin- ker und Loader. 28