KERNundMANEGMENT.pdf

Betriebssystemkerne Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Der Betriebssystemkern Enthält die grundlegenden Funktionen des Betriebssystems: Systemaufrufe,...

Betriebssystemkerne Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Der Betriebssystemkern Enthält die grundlegenden Funktionen des Betriebssystems: Systemaufrufe, Benutzerverwaltung, Prozessverwaltung inklusive Ausführungsreihenfolge (Scheduling), Interprozesskommunikation, Prozessumschalter (Dispatcher), Gerätetreiber, Speicherverwaltung, Dateisysteme zur Verwaltung von Dateien auf Speicherlaufwerken Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Der Betriebssystemkern Ist die Schnittstelle zur Hardware des Computers: Funktionalitäten im Betriebssystemkern 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) Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Der Betriebssystemkern Ein Schichtmodell ist eine strukturierte Darstellung eines Systems, bei dem die verschie- denen Funktionen oder Kompo- nenten in Schichten oder Ebenen organisiert sind. Jede Schicht erfüllt bestimmte Aufgaben und stellt Dienste für die darüber und darunter liegenden Schichten bereit. Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Der Betriebssystemkern Der Kernel-Bereich ist privilegiert stellt die Infrastruktur für die Prozesse und ihre Interaktionen bereit. Da der Kernel den direkten Zugriff auf die Hardware hat, ist von hier alles möglich. Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Die Anwendungsschicht Der User-Bereich ist nicht privilegiert, kann aber darauf aufbauende Funktionalitäten bereitstellen. Der Zugriff auf die Hardware erfolgt alleinig durch die im Kernel bereitgestellten Funktionalitäten (Sytem-Calls). Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Monolithische Kerne Ein Monolith enthällt alle Funktionalitäten eines Betriebssystems. Pro: Con: Die Ausführungsgeschwindigkeit ist besser Nachteilig ist, dass abgestürzte als mit anderen Architekturen da weniger Komponenten des Kerns nicht separat neu Prozesswechsel notwendig sind. Zudem ist gestartet werden können und eventuell durch jahrelange Entwicklungstätigkeit das gesamte Betriebssystem zum Absturz eine gewachsene Stabilität vorhanden. bringen. MS-DOS, FreeDOS, Windows 95/98/ME , Mac OS (bis Version 8.6), OS/2 … Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Minimale Kerne (Microkernel) Hier befinden sich nur die nötigsten Funktionen im Kernel. Pro: Con: Alle weiteren Funktionalitäten laufen als Nachteilig ist, dass abgestürzte Dienste bzw. Server im User-Modus. Die Komponenten des Kerns nicht separat neu ausgelagerten Funktionalitäten sind gestartet werden können und eventuell dadurch leichter austauschbar. das gesamte Betriebssystem zum Absturz Ein minimaler Kern bietet i.d.R eine bringen. bessere Stabilität und Sicherheit. AmigaOS, MorphOS, Tru64, QNX Neutrino, Symbian, Minix, Amoeba … Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Hybride Kerne Hier geht man einen Kompromiss ein. Diese enthalten Komponenten die, aus Geschwindigkeitsgründen, zusätzlich in den Kernel aufgenommen werden. Pro: Con: Theoretisch ergibt sich eine höhere Keine klare Definition was in den Kernel Geschwindigkeit als bei minimalen Kernen integriert wird. Daher differieren diese und eine höhere Stabilität als bei Systeme sehr stark und können zu einer monolithischen Kernen. fehlenden Unterstützung der Hardware- und Software-Hersteller führen. Windows seit NT 3.1, Apple Mac OS X, ReactOS, BeOS, ZETA … Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne / Vergleich Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Alternative Architekturen Der Flaschenhals aller bestehenden Systeme liegt in Ihren Schichtmodellen begründet. Eine Anwendung hat keinen direkten Zugriff auf die Hardware. Sämmtliche Kommunikation und Datenfluß wird über Bibliotheken und den Kernel abgewickelt. Um die Kommunikation und den Datenfluß zu erhöhen, wäre ein direkter Kontakt zwischen Anwendung und Hardware notwendig. Die Zugangskontrolle erfolgt weiterhin über Bibliotheken und Kernel. Ein solches Betriebsystem hätte einen geringeren Umfang (Sicherheit). Es könnte sogar selbst als Bibliothek fungieren und würde durch den Linker in eine Anwendung integriert werden. Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Programmierschnittstellen Ein Systemaufruf (System Call) ist eine Programmierschnittstelle (API), die es Anwendungsprogrammen ermöglicht, auf die Dienste und Ressourcen des Betriebssystems zuzugreifen. Wenn ein Programm eine Aktion ausführen will, die besondere Berechti- gungen erfordert oder die Kontrolle über die Hardware benötigt, verwendet es Systemaufrufe, um diese Dienste vom Betriebssystem anzufordern. Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Programmierschnittstellen Die Implementierung von Systemaufrufen hängt stark von der verwendeten Hardware, der Architektur und letztlich auch dem benutzten Betriebssystem ab. In der Regel wird heute ein Systemaufruf mit Softwareinterrupts oder anderen Spezialinstruktionen der CPU realisiert. Bei älteren Systemen findet meist einfach nur ein Sprung an eine fest definierte Adresse statt, an der der Systemaufruf oder ein Sprungbefehl zu diesem implementiert ist. Beim einem Moduswechsel gibt ein User-Prozess die Kontrolle über den Hauptprozessor an den Betriebssystemkern ab und ist für die benötigte Zeit unterbrochen. Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Programmierschnittstellen Wann werden Systemaufrufe genutzt? Software User-Mode Berechtigungen Ressourcenverwaltung System Call Kommunikation mit Hardware Prozesssteuerung Betriebssystem Kernel-Mode Netzwerkkommunikation Zeitverwaltung Hardware Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Programmierschnittstellen In der Praxis ist die Nutzung eines direkten Systemaufrufs nicht empfehlens- wert. Solche Software ist schlecht portierbar, da nicht alle Systemaufrufe bei den verschiedenen Betriebssystemfamilien identisch sind. Es ist nicht garantiert, dass neue Versionen eines Betriebssystemkerns nicht auch Veränderungen an Systemaufrufen enthält. Bei der Entwicklung von Software sollte auf die Funktionen von Bibliotheken zurückgegriffen werden. Diese befinden sich, mit entsprechenden Wrapper- Funktionen, logisch zwischen den Benutzerprozessen und dem Betriebssystemkern. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozessverwaltung Die Prozessverwaltung ist eine der grundlegenden Funktionalitäten eines Betriebssystems. Jeder Prozess im Betriebssystem ist eine Instanz eines Programms, das ausgeführt wird. Auf einem modernen Computersystem sind immer mehrere Prozesse in Ausführung. Der Hauptprozessor wird beim Mehrprogrammbetrieb im raschen Wechsel (ms) zwischen den Prozessen hin- und hergeschaltet. Jeder Prozess umfasst außer dem Programmcode noch seinen Prozesskontext, der von den Kontexten anderer Prozesse unabhängig ist. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Beispiel: Terminalbefehl – top Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesskontext Der Kontext eines Prozesses bezieht sich auf den aktuellen Zustand und die Informationen, die benötigt werden, um einen bestimmten Prozess in einem Betriebssystem auszuführen. Jeder laufende Prozess hat seinen eigenen Kontext, der Informationen über den Zustand des Prozesses und seine Ausführungsumgebung enthält. Der Prozesskontext ist entscheidend für die Wiederaufnahme der Ausführung eines Prozesses nach einem Unterbrechungspunkt, beispielsweise nach einem Wechsel zu einem anderen Prozess oder nach einem Systemaufruf. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesskontext Der Prozesskontext ist entscheidend, um die Multitasking-Fähigkeiten eines Betriebssystems zu unterstützen. Wenn ein Betriebssystem zwischen verschiedenen Prozessen wechselt, muss es den aktuellen Kontext speichern und den Kontext des nächsten auszuführenden Prozesses wiederherstellen. Der schnelle und effiziente Wechsel des Prozesskontexts trägt dazu bei, die Illusion zu schaffen, dass mehrere Prozesse gleichzeitig ausgeführt werden. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozessstatus Zugriffsrechte und Programmzähler Zustände Prozesskontext Dateien und Registerinhalte Ressourcen Stack und Stackzeiger Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Hardwarekontext Der Hardwarekontext eines Prozesses bezieht sich auf den Teil des Prozesskontexts, der Informationen über den Zustand der verwendeten Hardware enthält, die von einem bestimmten Prozess genutzt wird. Dieser Zustand umfasst Informationen über die CPU-Register, den Zustand des Hauptspeichers (RAM), den Zustand der CPU-Flags und andere hardwarenahe Daten. Der Hardwarekontext ist entscheidend für die Wiederaufnahme der Ausführung eines Prozesses nach einer Prozess-Unterbrechung. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Hardwarekontext Befehlszähler (Program Counter, Instruction Pointer) Stackpointer Basepointer Befehlsregister (Instruction Register) Akkumulator Page-Table Base Register Page-Table Length Register Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Systemkontext Der Systemkontext eines Prozesses bezieht sich auf den Teil des Prozesskontexts, der Informationen über alle Systemressourcen und den Zustand des Betriebssystems enthält, die von einem bestimmten Prozess genutzt werden. Dieser Kontext ist wichtig, um die Systemaufrufe und den Zugriff auf privilegierte Ressourcen zu verwalten. Der Systemkontext wird bei einem Wechsel von Benutzermodus zu Kernelmodus und zurück benötigt. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Systemkontext Eintrag in der Prozesstabelle Prozessnummer (PID) Prozesszustand Information über Eltern- oder Kindprozesse Priorität Zugriffsrechte auf Ressourcen Erlaubte Nutzungsmengen (Quotas) einzelner Ressourcen Laufzeit Geöffnete Dateien Zugeordnete Geräte Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesstabelle / -kontrollblock Die Prozesstabelle und der Prozesskontrollblock (PCB) sind Konzepte in der Betriebssystem- architektur, die zur Verwaltung von Prozessen und ihren Zuständen verwendet werden. Diese sind in der Regel im Kontext von Multitasking-Betriebssystemen relevant. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesstabelle Die Prozesstabelle ist eine Datenstruktur im Betriebssystem, die Informationen über alle aktiven Prozesse im System enthält. Jeder Prozess hat einen Eintrag in dieser Tabelle. Die Prozesstabelle dient als Index für alle laufenden Prozesse und bietet eine einfache Möglichkeit für das Betriebssystem, Informationen zu einem bestimmten Prozess schnell abzurufen. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesstabelle Prozess-ID (PID): Eine eindeutige Kennung für jeden Prozess Zustand des Prozesses (laufend, bereit, blockiert usw.) Priorität des Prozesses für das Scheduling Zeiger auf den Prozesskontrollblock (PCB) des Prozesses Andere Ressourceninformationen Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesskontrollblock (PCB) Der Prozesskontrollblock ist eine Datenstruktur, die alle Informationen enthält, die das Betriebssystem benötigt, um einen bestimmten Prozess zu verwalten. Jeder aktive Prozess hat seinen eigenen PCB, der vom Betriebssystem erstellt und aktualisiert wird. Der PCB wird im Speicher gehalten und enthält den Kontext des Prozesses. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesskontrollblock (PCB) Zustand des Prozesses und Programmzähler Registerinhalte, einschließlich der CPU-Register Zeiger auf den Stack des Prozesses Informationen über geöffnete Dateien und andere Ressourcen Planungs- und Scheduling-Informationen wie Priorität und Wartezeit Informationen über den Prozesseigner, Zugriffsrechte und Sicherheitsinformationen Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesszustände In einem Multitasking-Betriebssystem durchläuft ein Prozess verschiedene Zustände während seiner Lebensdauer. Diese Zustände werden als Prozesszustände bezeichnet, und sie geben den aktuellen Status eines Prozesses im System an. Gängige Zustände sind: Bereit (Ready) Laufend (Running) Blockiert (Blocked) Beendet (Terminated) Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 2-Zustands-Modell Das 2-Zustands-Modell ist einfach und bietet einen grundlegenden Rahmen für das Verständnis von Prozesszuständen. In der Praxis sind Betriebssysteme jedoch oft komplexer und verwenden erweiterte Modelle mit mehr Zuständen, um verschiedene Aspekte der Prozessverwaltung besser zu berücksichtigen. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 2-Zustands-Modell Prozesse im Zustand untätig werden in einer Warteschlange gespeichert, in der sie auf ihre Ausführung warten. Die Liste wird nach einem Algorithmus sortiert, der sinnvollerweise die Prozesspriorität und/oder die Wartezeit berücksichtigt. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 2-Zustands-Modell Das 2-Zustands-Modell hat den Vorteil, dass es sehr einfach realisierbar ist, es hat aber einen konzeptionellen Fehler. Dieser besteht in der Annahme, dass alle Prozesse jederzeit zur Ausführung bereit sind. In der Praxis ist das nicht der Fall, denn es gibt in einem Betriebssystem mit Mehrprogrammbetrieb auch immer Prozesse, die blockiert (blocked) sind. Mögliche Gründe: Prozess wartet auf die Ein-/Ausgabe eines Geräts Prozess wartet auf das Ergebnis eines anderen Prozesses Prozess wartet auf die Reaktion eines Benutzers Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 3-Zustands-Modell Daraus resultiert dann das 3-Zustands-Prozessmodell. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Ereignisbezogene Warteschlangen Für jedes Ereignis, auf das mindestens ein Prozess wartet, legt das Betriebssystem eine Warteschlange an. Tritt ein Ereignis ein, werden alle in der entsprechenden Warteschlange befindlichen Prozesse in die Warteschlange mit den Prozessen im Zustand bereit (ready) überführt. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 5-Zustands-Modell Bei Computern mit wenig Ressourcen kann es sinnvoll sein, die Anzahl der ausführbaren Prozesse zu limitieren, um Speicher zu sparen und den Grad des Mehrprogrammbetriebs festzulegen, ist es sinnvoll, das 3-Zustands- Prozessmodell um zwei weitere Prozesszustände zu erweitern. neu (new): beendet (exit): Prozesse, deren PCB das Betriebssystem beendet (exit): Abgearbeitete oder zwar bereits erzeugt hat, die aber noch abgebrochene Prozesse deren PCB und nicht in die Warteschlange für den Zustand Eintrag in der Prozesstabelle nicht entfernt bereit eingefügt sind. wurden. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 5-Zustands-Modell Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 6-Zustands-Modell Ist nicht genügend physischer Hauptspeicher für alle Prozesse verfügbar, müssen Teile von Prozessen auf den Auslagerungsspeicher (Swap) ausgelagert werden. Soll das Betriebssystem in der Lage sein, bei Bedarf Prozesse auszulagern, die im Zustand blockiert (blocked) sind, muss ein weiterer Prozesszustand suspendiert (suspended) eingeführt werden. Dadurch steht den Prozessen in den Zuständen rechnend und bereit mehr Hauptspeicher zur Verfügung. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 6-Zustands-Modell Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 7-Zustands-Modell Wurde ein Prozess suspendiert, ist es besser, den frei gewordenen Platz im Hauptspeicher zu verwenden, um einen ausgelagerten Prozess zu aktivieren, als ihm einen neuen Prozess zuzuweisen. Das ist aber nur dann sinnvoll, wenn der aktivierte Prozess nicht mehr blockiert ist. Im 6-Zustands-Modell fehlt die Möglichkeit, die ausgelagerten Prozesse in blockierte und nicht-blockierte ausgelagerte Prozesse zu unterscheiden. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 7-Zustands-Modell Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das Zustands-Modell von Linux Das Prozessmodell von Linux kommt dem 7-Zustands-Prozessmodell schon sehr nahe. Der offensichtlichste Unterschied ist, dass der Zustand rechnend in der Praxis in die beiden Zustände benutzer rechnend (user running) für Prozesse im Benutzermodus und kernel rechnend (kernel running) für Prozesse im Kernelmodus unterteilt ist. Zudem heißt der Zustand beendet (exit) unter Linux Zombie. Ein Zombie- Prozess ist zwar fertig abgearbeitet (via Systemaufruf exit), aber sein Eintrag in der Prozesstabelle existiert noch so lange, bis der Elternprozess den Rückgabewert (via Systemaufruf wait) abgefragt hat. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das Zustands-Modell von Linux Dipl.-Ing. (FH) Michael Herzog Dipl.-Ing. (FH) Michael Herzog 14