betriebssystemarchitektur
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
betriebssystemarchitektur [2024/01/17 08:57] – [Komponenten des Kernels] torsten.roehl | betriebssystemarchitektur [2024/10/11 08:47] (aktuell) – torsten.roehl | ||
---|---|---|---|
Zeile 15: | Zeile 15: | ||
{{ : | {{ : | ||
+ | |||
+ | |||
+ | In der obigen Betriebssystem-Architektur ist vereinfacht ein Rechensystem dargestellt. Im unteren Teil befindet sich der Kernel, im oberen die sonstigen Betriebssystemkomponenten (Services und Bibliotheken) . | ||
+ | |||
+ | Der Betriebssystemkern besteht damit im Wesentlichen aus den folgenden Komponenten, | ||
+ | |||
+ | * Systemcall-Interface | ||
+ | * Prozessmanagement | ||
+ | * Speicher-Management | ||
+ | * IO-Management | ||
+ | * Gerätetreiber | ||
+ | |||
==== Systemcall-Interface ==== | ==== Systemcall-Interface ==== | ||
+ | Applikationen können die Dienste, die ein Betriebssystem zur Verfügung stellt, über das Systemcall-Interface in Gebrauch nehmen. Technisch ist diese Schnittstelle über Software-Interrupts realisiert. Möchte eine Applikation einen Dienst (zum Beispiel das Lesen von Daten aus einer Datei) nutzen, löst sie einen Software-Interrupt aus und übergibt dabei Parameter, die den vom Kernel auszuführenden Dienst hinreichend charakterisieren. Der Kernel selbst führt nach Auslösen des Software-Interrupts die zugehörige Interrupt-Service-Routine (ISR) aus und gibt der aufrufenden Applikation einen Rückgabewert zurück.\\ | ||
+ | |||
+ | Das Auslösen des Software-Interrupts wird im Regelfall durch die Applikationsentwickler nicht selbst programmiert. Vielmehr sind die Aufrufe der Systemcalls in den Standardbibliotheken versteckt und eine Applikation nutzt eine dem Systemcall entsprechende Funktion in der Bibliothek.\\ | ||
+ | |||
+ | Die Anwendungen fordern die Dienste des IO-Managements über Systemcalls an. Damit wird bei einer Anwendung nicht nur der Code abgearbeitet, | ||
+ | |||
+ | Welche Systemcalls in Linux vorhanden bzw. implementiert sind, ist in der Datei < | ||
+ | |||
+ | < | ||
+ | #define __NR_exit | ||
+ | #define __NR_fork | ||
+ | #define __NR_read | ||
+ | #define __NR_write | ||
+ | #define __NR_open | ||
+ | </ | ||
+ | Der Systemcall mit der Nummer 1 ist der Aufruf, um einen Rechenprozess zu beenden (exit); das Erzeugen eines neuen Rechenprozesses erfolgt über den Systemcall fork, welcher die Nummer 2 hat. Über den Systemcall mit der Nummer 3 (read) lassen sich Daten aus Dateien oder von Geräten lesen. Kernel 2.6 bietet mehr als 270 unterschiedliche Systemcalls. | ||
+ | |||
==== Prozessmanagement ==== | ==== Prozessmanagement ==== | ||
+ | Eine zweite Komponente des Betriebssystemkerns stellt das Prozess-Subsystem dar. Im Wesentlichen verhilft es Einprozessorsystemen (Uniprocessor System, UP) dazu, mehrere Applikationen quasi parallel auf dem einen Mikroprozessor (CPU) abarbeiten zu können. | ||
+ | |||
+ | Jeder Rechenprozess besteht aus <color # | ||
+ | |||
+ | Um Ressourcen (Speicher) zu sparen, können sich mehrere Rechenprozesse auch Segmente teilen. Wird beispielsweise dieselbe Office-Applikation zweimal gestartet, wird vom Betriebssystemkern nicht zweimal ein identisches Codesegment angelegt, sondern für beide Rechenprozesse nur eins.\\ | ||
+ | |||
+ | Teilen sich zwei Rechenprozesse sowohl das Codesegment als auch das Datensegment, | ||
+ | |||
+ | | {{ : | ||
+ | |Abbildung: Rechenprozesse (Tasks und Threads) | | ||
+ | Da auf einer CPU nicht wirklich mehrere Rechenprozesse gleichzeitig ablaufen können, sorgt das Prozessmanagement dafür, dass jeweils nur kurze Abschnitte (ca: 100 ms) der einzelnen Rechenprozesse hintereinander bearbeitet werden. Am Ende einer derartigen Bearbeitungsphase unterbricht das Betriebssystem – ausgelöst durch einen Interrupt – den gerade aktiven Rechenprozess und sorgt dafür, dass ein Folgeabschnitt des nächsten Rechenprozesses bearbeitet wird. Hierdurch entsteht der Eindruck der Parallelität. Welcher der rechenbereiten Tasks bzw. Threads wirklich rechnen darf, wird durch einen Scheduling-Algorithmus bestimmt, der auch kurz als Scheduler bezeichnet wird. Den Vorgang der Auswahl selbst nennt man Scheduling. | ||
+ | |||
+ | |{{ : | ||
+ | |Abbildung: Rechenprozesszustände| | ||
+ | |||
+ | Konkurrieren zum Beispiel drei Rechenprozesse auf einem Einprozessorsystem um die Ressource CPU, dann rechnet zu einem Zeitpunkt maximal einer der drei. Dieser eine Rechenprozess ist im Zustand aktiv. Die anderen beiden Rechenprozesse werden dagegen unterbrochen (// | ||
+ | |||
+ | Eine weitere Änderung gegenüber dem vereinfachten Prozesszustandsmodell bringt der Linux-Kernel durch den Zustand Zombie ('' | ||
+ | |||
==== Speicher-Management ==== | ==== Speicher-Management ==== | ||
+ | Die dritte Komponente moderner Betriebssysteme ist die Speicherverwaltung Hard- und Software machen es möglich, dass in Programmen Adressen (so genannte logische Adressen) verwendet werden, die nicht den physikalischen Adressen entsprechen. Der Entwickler kann Speicherbereiche (Segmente) definieren, die er dann – durch die Hardware unterstützt – bezüglich lesender und schreibender Zugriffe überwachen kann. Darüber hinaus kann sichergestellt werden, dass aus einem Datensegment kein Code gelesen wird bzw. in ein Codesegment keine Daten abgelegt werden.\\ | ||
+ | |||
+ | Systemtechnisch wird dies dazu genutzt, sowohl dem Betriebssystemkern als auch jeder einzelnen Applikation eigene Segmente zuzuordnen. Damit wird verhindert, dass eine Applikation auf den Speicher der anderen Applikation oder gar auf den Speicher des Betriebssystemkerns zugreift. Der Speicherbereich, | ||
+ | |||
+ | Allerdings kann aber auch der Kernel, und hier insbesondere der Gerätetreiber, | ||
+ | |||
+ | Die Umrechnung logischer Adressen auf physikalische Adressen wird durch Funktionen innerhalb des Kernels durchgeführt. Das funktioniert aber immer nur für die eine Task, die sich im Zustand aktiv befindet (auf die also die globale Variable '' | ||
==== IO-Management ==== | ==== IO-Management ==== | ||
+ | Ein vierter großer Block des Betriebssystemkerns ist das IO-Management Dieses ist für den Datenaustausch der Programme mit der Peripherie, den Geräten, zuständig.\\ | ||
+ | |||
+ | Das IO-Management hat im Wesentlichen zwei Aufgaben:\\ | ||
+ | |||
+ | - Ein Interface zur systemkonformen Integration von Hardware anzubieten und | ||
+ | - eine einheitliche Programmierschnittstelle für den Zugriff auf Peripherie zur Verfügung zu stellen. | ||
+ | |||
+ | Idee dieses Programmier-Interfaces ist es, den Applikationen jegliche Peripherie in Form von Dateien zu präsentieren, | ||
+ | |||
+ | **Beispiel | ||
+ | < | ||
+ | crw-rw---- | ||
+ | |||
+ | In Beispiel Datei und Gerätedatei ist die Ausgabe des Kommandos '' | ||
==== Gerätetreiber ==== | ==== Gerätetreiber ==== | ||
+ | Die fünfte Komponente eines Betriebssystems sind die Gerätetreiber Als Softwarekomponente erfüllen sie eine überaus wichtige Funktion: Sie steuern den Zugriff auf alle Geräte! Erst der Treiber macht es einer Applikation möglich, über ein bekanntes Interface die Funktionalität eines Gerätes zu nutzen.\\ | ||
+ | |||
+ | Ganz verschiedene Arten von Hardware werden über Gerätetreiber in ein Betriebssystem integriert: Drucker, Kameras, Tastaturen, Bildschirme, | ||
+ | |||
+ | Da diese Geräte darüber hinaus über diverse Bussysteme (z.B. PCI, SCSI, USB) angeschlossen werden können, haben Betriebssysteme im Allgemeinen und Linux im Besonderen unterschiedliche Treiber-Subsysteme\\ | ||
+ | |||
+ | Während traditionell zwischen zeichenorientierten Geräten (// | ||
+ | |||
+ | |||
+ | * Character-Devices | ||
+ | * Block-Devices | ||
+ | * Netzwerk | ||
+ | * SCSI (Small Computer System Interface) | ||
+ | * USB (Universal Serial Bus) | ||
+ | * IrDA (Infrared Data Association) | ||
+ | * Cardbus und PCMCIA | ||
+ | * Parallelport | ||
+ | * I2C (serielles Kommunikationsprotokoll) | ||
+ | * I2O (Intelligent Input/ | ||
+ | |||
+ | Für diese Vielfalt von Subsystemen ist die Applikationsschnittstelle erweitert worden. Nunmehr lassen sich folgende Interfaces differenzieren: | ||
+ | |||
+ | * Das Standard-API (mit Funktionen wie '' | ||
+ | * Kommunikations-API | ||
+ | * Card-Services | ||
+ | * Multimedia-Interfaces (z.B. Video4Linux) | ||
+ | |||
+ | Realisiert sind die Interfaces zumeist auf Basis eines Sets standardisierter Datenstrukturen und IO-Controls (um das Systemcall-Interface nicht erweitern zu müssen).\\ | ||
+ | |||
+ | Gerätetreiber sind integraler Bestandteil des Betriebssystemkerns. Soll ein Kernel mit einem neuen Treiber versehen werden, muss theoretisch der gesamte Kernel neu generiert werden. Treiber, die auf diese Art mit dem Betriebssystemkern verbunden sind, nennt man <color # | ||
+ | |||
+ | Daneben bietet Linux auch die Möglichkeit, | ||
+ | Kernelmodul</ | ||
+ | |||
+ | Die Funktionen, die ein Gerätetreiber-Entwickler zu kodieren hat, sind: | ||
+ | |||
+ | - Funktionen, die zur Einbindung des Gerätetreibers in den Kernel notwendig sind, | ||
+ | - Funktionen, die durch die Applikation angestoßen (getriggert) werden und | ||
+ | - Funktionen, die durch den Betriebssystemkern getriggert werden. | ||
+ | |||
+ | |||
==== Sonstige Betriebssystemkomponenten ==== | ==== Sonstige Betriebssystemkomponenten ==== | ||
+ | Ein Betriebssystem besteht nicht nur aus dem Betriebssystemkern, | ||
+ | |||
+ | Auch bei der **Treiberentwicklung** sind gegebenenfalls Bibliotheken mit einzuplanen, | ||
+ | |||
+ | Betriebssystemapplikationen werden oft auch Dienste genannt. Diese Dienste gilt es jedoch gegenüber den Diensten des Betriebssystemkerns, | ||
+ | |||
+ | Ein solcher Service ist beispielsweise der // | ||
+ | |||
+ | ---- | ||
+ | <color # | ||
betriebssystemarchitektur.1705481867.txt.gz · Zuletzt geändert: 2024/01/17 08:57 von torsten.roehl