Betriebssystem-Architekturen

Betriebssystem-Architekturen
Prof. Dr. Margarita Esponda
Freie Universität Berlin
Betriebssystem-Architekturen

Monolithische Systeme

Mikrokernel-Architekturen

Hybride-Architekturen

Systeme mit Objektorientierten Techniken

Virtuelle Maschinen
M. Esponda-Argüero
Betriebssystem-Architektur
Die Anforderungen an ein Betriebssystem können sehr
unterschiedlich sein.
Ein Echtzeit-Betriebssystem für ein kleines Gerät unterscheidet
sich sehr stark von einem Server-Betriebssystem, das zum
Beispiel Informationen in einer Datenbank sucht.
Was soll das
Betriebssystem leisten?
Policy
Wie soll alles
implementiert werden?
Mechanism
M. Esponda-Argüero
Betriebssystem-Architektur
Wenn die Anforderungen (Policy) getrennt von
der Implementierung (Mechanism) sind,
gewinnt man an Flexibilität.
Im schlimmsten Falle führt jede Veränderung
der Anforderungen zu einer Veränderung der
Implementierung.
M. Esponda-Argüero
Betriebssystem-Architektur
Viele kommerzielle Betriebssysteme hatten am Anfang keine
richtige Struktur, weil Betriebssysteme mit sehr starken
Hardware-Einschränkungen implementiert werden mussten.
- sehr wenig Hauptspeicher
- keine Festplatte
- langsame Prozessoren
- Assembler-Programmierung
Beispiel:
MS-DOS
M. Esponda-Argüero
Einfache Betriebssystemstruktur
Beispiel:
MS-DOS Disk Operating System 1981
Grundlegende Ein-/AusgabeFunktionalität
"Basic Input/Output System"
-
Einbenutzer-System "single-user"
-
single-task ⇒ kein Scheduler
-
keine Vernetzung
-
keine virtuelle Speicher
-
kein Sicherheits-System
Silberschatz
M. Esponda-Argüero
Betriebssystem-Architektur
Erste Betriebssysteme, die nicht nur im Assembler geschrieben worden sind:
Master Control Program (MCP)
Burroughs
1961
Executive Systems Programming Language
(Erweiterung von Algol)
Open Source
Virtuelle Speicher
MULTICS
MIT
PL/1
Modularisiert
Multitasking (time-sharing)
single level store (mapped segments)
dynamische Bindung (dynamic linking)
on-line-Konfigurierung
Multiprozessor-System
Sicherheitssystem
Hierarchisches Dateisystem
Fernando J. Corbató
sehr innovativ!
UNIX
Bell Labs
1964 - 2000
C
Einfachheit
M. Esponda-Argüero
Schichtenstruktur
Hier versucht man das
Betriebssystem in
verschiedenen Schichten
zu organisieren, die von
primitiven Funktionen zu
komplexeren Funktionen
gehen.
Probleme
• Effizienz
Silberschatz
• Klassifizierung der
verschiedenen Schichten
M. Esponda-Argüero
Betriebssystemarchitektur
Monolithische Systeme
Die häufigste Struktur von Betriebssystemen ist die
monolithische Struktur.
Das Betriebssystem ist als eine Menge von
Prozeduren realisiert.
Jede Prozedur kann von jeder anderen aufgerufen werden.
Die meisten monolithischen Betriebssysteme haben
eine sehr einfache Struktur.
Linux wird als monolithisches System eingeordnet.
M. Esponda-Argüero
Einfaches Monolithisches Betriebssystem
Benutzerprogramme
Programm1
Programm2
Systemaufruf
.
.
.
.
.
...
Programm3
.
.
.
Kernel-Aufruf
Dienstprozedur1
Utility-Prozedur1
Dienstprozedur2
Utility-Prozedur2
.
.
.
.
.
.
Dienstprozedur3
Utility-Prozedur3
Main-Prozedur
Kernel-modus
M. Esponda-Argüero
Mikrokernel-Architekturen
In den 80er Jahren wurde der Kernel von Unix-Betriebssystemen
zu groß und komplex.
In einigen Betriebssystemen wird versucht so viel Funktionalität wie
möglich außerhalb des Kernels zu verlagern, so dass ein minimaler
Mikrokern übrig bleibt.
Die Funktionalität wird durch Server-Prozesse durchgeführt und
der Mikrokern muss nur die Kommunikation zwischen Client- und
Server-Prozessen durchführen.
Carnegie Mellon University entwickelte 1985-1994 das Mach
Betriebssystem.
M. Esponda-Argüero
Mikrokernel
Bibliotheken
Prozess1
(Kunde)
…
Prozessn
(Kunde)
Dateiverwaltung
Server
Grundfunktionen zur
Synchronisation und
Kommunikation
Mikrokernel
Netzwerk
Server
…
Gerätetreiber
Server
Funktionen zur Speicherund Prozessverwaltung
Usermodus
Kernelmodus
Hardware
M. Esponda-Argüero
Mikrokernel
Eigenschaften:
- Bessere Modularisierung
- Mikrokernel mit stark reduzierter Funktionalität
-
minimale Prozessverwaltung
-
minimale Speicherverwaltung
-
Hauptaufgabe ist die Kommunikation mittels
Nachrichtenverkehr
Vorteile:
- übersichtlicher
- flexibler
Problem:
ACM
- Kommunikations-Overhead
M. Esponda-Argüero
Mach-Betriebssystem
1985-1994
Carnegie Mellon University
Ersetzung des BSD-Kernel
Die Probleme wurden größer:
1990
60% Wachstum der CPU-Leistung
7% Verbesserung der Speicher-Zugriffe
1997
Richard Rashid
50% langsamer als UNIX
Probleme innerhalb der IPC-Operationen
- Menory-Mapping
- Kontrolle von port-Zugriffsrechten
- Nachrichten-Validierung
M. Esponda-Argüero
Mach-Betriebssystem
Mac OS X
Anwendungsbereich
gemeinsame Dienste
KernelBereich
Beispiele
BSD
Mach
QNX (Echtzeitbetriebssystem)
Darwin (Mac OS X Kernel)
Interessante Beispiele:
Windows NT 4.0
Windows XP
M. Esponda-Argüero
MULTICS
UNICS
UNIX 1
UNIX 6
UNIX Syst. III
BSD-Unix
Minix
Xenix
BSD-4.2
Linux
BSD-4.3
Mach
Next
GNU Hurd
Mac OS X
Linux 2.6
Suse
Darwin
www.javipas.com/wp-content/unix_desktop_macosx_1600x1200.jpg
Devian
Ubuntu
Monolithisch vs. Mikrokernel vs. Hybride-Systeme
System Call
Applications
VFS
IPC, File System
Application
IPC
Device
Server
File
Server
VM, Scheduling, Basic IPC, …
Hardware
Hardware
Monolithisch
Mikrokernel
UNIX
Server
File
Server
UNIX
Server
Application
IPC
Scheduler, Virtual Memory
Device Drivers, Dispatcher …
Applications
Applications
Device
Server
VM, Scheduling, Basic IPC, …
Hardware
Hybride-Kernel
M. Esponda-Argüero
Objektorientierte Struktur
Modernere Lösung
• Modularisierte Struktur.
• Module werden am Anfang und zur Laufzeit dynamisch geladen.
• Es gibt einen zentralen Kernel (core kernel) und verschiedene
ladbare Module.
• Alle Module definieren eine saubere Schnittstelle.
• Das zentrale Modul kann beliebige Module laden und problemlos
und effizienter mit allen Modulen kommunizieren (ohne
Nachrichtenverkehr).
• Höhere Schichten können Klassen aus tieferer Schicht
erweitern.
M. Esponda-Argüero
Mikrokernel + Objektorientierte-Techniken
Die Forschung geht weiter, weil Mikrokernel
leicht zu erweitern,
einfacher zu portieren,
und sicherer sind.
Optimierungen im Speicherverwaltung-Bereich
Mikrokernel sind besonders interessant für die Entwicklung
von Verteilten Betriebssystemen
Plan 9
2K
Inferno
The Sprite OS
Mach
AgentOS
WebOS
Bell Labs
UIUC
Vita Nuova
Berkeley
CMU
UCI
Berkeley
M. Esponda-Argüero
Struktur mit objektorientierten Programmiertechniken
Solaris
Schedulerklassen
Gerätetreiber
Dateisysteme
Verschiedene
Dienste
Core Kernel
Streamming
Systemaufrufe
Ausführbare
Formate
Das Mac OS X Betriebssystem hat eine hybride Struktur, die
Mikrokern und objektorientierte Programmiertechniken kombiniert.
M. Esponda-Argüero
Symbian OS
Geschichte
• Es beginnt mit der Entwicklung der Handheld-Geräte (PDAs)
Ende der 1980er
32-Bit-EPOC-Plattform
entwickelt für PDAs
Echtzeitperformance
einer SmartphonePlattform
Symbian OS
• Kommunikation als zentrale Aufgabe
• Minimale Hardwareabhängigkeit
M. Esponda-Argüero
Ergebnis:
Symbian OS
• modernes 32-Bit Betriebssystem
• objektorientiert
• mit einer Mikrokernelarchitektur
• hoher Modularisierungsgrad und Plattformunabhängigkeit
• Client/Server-Architektur (EPOC Engine-Modell)
• ein weiches Echtzeitsystem ( für Multimedia )
• unterstützt Desktop-Funktionalität wie
- Multitasking, Multithreading
- erweiterbares Speichersystem
• effiziente Kommunikation
• sehr verbreitet in den Smartphones
• 2008 kaufte Nokia Symbian
• Ankündigung, dass Symbian OS 2009 open source werden soll
M. Esponda-Argüero
Objektorientiert
• Das Symbian-Betriebssystem wurde von Anfang an
objektorientiert konzipiert.
• Die gesamte Nutzung der Systemaufrufe und Kern-Funktionen
läuft über Schnittstellen.
• Der Kern stellt Kerndienste nur über Objekte zur Verfügung.
• Die Benutzung von Kernobjekten verläuft über Handles.
• Betriebsmittelschutz wird durch die Belegung von Objekten
realisiert.
• Die Details der Systemimplementierung bleiben vor
Benutzerprogrammen verborgen.
M. Esponda-Argüero
Mikrokerndesign
• Das Symbian OS wurde als ein mikrokernbasiertes
Betriebssystem entwickelt.
• Im Kern gibt es nur eine minimale Anzahl von
Systemfunktionen und Daten.
• Der Zugriff auf Systemressourcen erfolgt nur durch
Verbindungen zu entsprechenden Ressourcen-Servern.
• Die meisten Systemfunktionen wurden auf Server des
Benutzeradressraums verschoben.
• Die Server erhalten Handles auf Systemobjekte und führen mit
diesen, wenn nötig, Systemaufrufe aus.
M. Esponda-Argüero
Mikrokerndesign
Anwendungen
Usermodus
Middleware
Server
Server
Kernelmodus
Server
Server
Server
Mikrokern
+ Gerätetreiber
M. Esponda-Argüero
Mikrokerndesign
Vorteile
• Neue Implementierungen für Systemfunktionen können als
Systemobjekte entworfen werden und dynamisch in den Kern
eingefügt werden.
• Dateisysteme z.B. können zur Laufzeit zum Kern hinzugefügt
werden.
• Mikrokerne sind klein und können sehr schnell gebootet werden.
• Server können erst nach Bedarf geladen werden.
Nachteile
• Ein Systemaufruf benötigt einen Nachrichtenaustausch.
• Die Performance leidet durch das KommunikationsOverhead zwischen Objekten.
M. Esponda-Argüero
Nanokern
• Ein Nanokern wurde als Lösung für die Performanceprobleme
des Mikrokerns eingeführt.
• Der Nanokern stellt die grundlegendste Funktionalität zur
Verfügung, die von privilegierten Nano-Threads ausgeführt wird.
• Scheduling-Operationen
• Synchronisationsoperationen
• Unterbrechungsbehandlung
• Einfache Synchronisationsobjekte (Mutexe und Semaphore)
• Die meisten Funktionen dieser Ebene sind unterbrechbar.
M. Esponda-Argüero
Symbian-OS-Kernschicht
Funktionen mit einer komplexeren Implementierung werden in
den Symbian-OS-Kern verschoben.
Jede Funktion ist hier eine privilegierte Operation, die aus
primitiven Operationen des Nanokerns besteht.
• Threads im Benutzermodus
• Prozess Scheduling und Kontextwechsel
• dynamischer Speicher
• dynamisch ladbare Bibliotheken
• komplexe Synchronisation
• Objekt- und Interprozesskommunikation
• andere komplexe Objektdienste
• usw.
M. Esponda-Argüero
Kernstruktur von Symbian OS
dia
e
ltim
Telefon-Funktionen
Di
sp
lay
Mu
Nanokern
ts
e
ck
Symbian-OS-Kern
So
Mikrokern-Server
Benutzeranwendungen
M. Esponda-Argüero
Client-Server-Ressourcenzugriff
• Das Mikrokerndesign verwendet ein Client/Server-Modell
• Anwendungen sind die Clients
• Server sind Programme, die das Betriebssystem laufen lässt,
um den Zugriff auf die Ressourcen zu koordinieren.
Vorteile
passt besser zum objektorientierten Design und zur MikrokernArchitektur
Server können sich auf eine Klasse von Ressourcen
spezialisieren
geringere Entwicklungskosten
M. Esponda-Argüero
Client-Server-Ressourcenzugriff
Das Öffnen einer Datei
• Symbian stellt für den Zugriff auf Dateien und Verzeichnisse
einen Server bereit (Fileserver)
• Der Fileserver stellt eine Anwendungsschnittstelle (Client API)
zur Verfügung, um Verzeichnisse und Dateien zu verändern.
• Um mit dem Fileserver zu arbeiten, muss zuerst eine
Verbindung aufgebaut werden.
...
RFs session = iCoeEnv->FsSession();
Rfile file;
session.Connect();
...
file.Open(session,_L(Dateiname),DFileRead | EFileWrite);
file.Write(_L8( "Bla Bla Bla Bla" ));
session.Close();
...
M. Esponda-Argüero
Symbian OS
M. Esponda-Argüero
M. Esponda-Argüero
2011
Symbian
Apple
Android
M. Esponda-Argüero
Virtuelle Maschinen
Silberschatz
Die ersten virtuellen Maschinen wurden 1972 von IBM entwickelt.
Die Festplatte wurde in viele virtuelle Mini-Festplatten verwandelt.
Virtuelle Maschinen
Mehrere Exemplare einer VM laufen auf einer
realen Maschine.
Verschiedene Betriebssysteme können gleichzeitig
ausgeführt werden.
Prozesse
Prozesse
Prozesse
Linux
MacOS
Windows
VM1
VM2
VM3
Virtuelle Maschine Implementierung
Systemaufrufe
Ein- AusgabeOperationen
Hardware
Beispiel: IBM VM Betriebssystem
M. Esponda-Argüero
Virtuelle Maschinen
Vorteile:
• Mehr Schutz durch Isolierung zwischen den virtuellen
Maschinen.
• Sehr gut für die Forschung und Entwicklung von
Betriebssystemen.
• Neue Versionen des Betriebssystems können getestet
werden.
• Software kann sehr leicht in verschiedenen
Betriebssystemen getestet werden.
Beispiele:
• VMware
• Java virtuelle Maschine
• CLR für die .NET Framework
M. Esponda-Argüero
VMware-Architektur
Quelle: "Operating System Concepts". Silberschatz, Galvin, Gagne
Android-Betriebssystem
-
-
-
basiert auf Linux Kernel 2.6
-
mit Energieverwaltungssystem
-
verändertes Speicherverwaltungssystem
-
neue Treiber
Dalvik-VM als wichtigste Laufzeitumgebung
-
Register-Maschine
-
*.class ⇒ *.dex
Jedes Java-Programm läuft in einer eigenen
Dalvik-VM
-
mit eigenem Garbage-Collector
M. Esponda-Argüero
Android-Betriebssystem
Java
C/C++
Quelle: www.sigmadesigns.com/uploads/library/android.jpg