Aufwärts: hurd
Vorherige Seite: Das HURD-System
Unterabschnitte
- Mach: Unix-Emulation im User-Space - portierbar
- OO: zwar in C, und keine Vererbung, kennt aber die Klassen Port (
Sockets), Nachricht, Task (= Prozess), Threads, und Virtual Memory
- Authentifizierungsserver (Sicherheit bei Kommunikation mit anderen Tasks),
Prozeßserver (CORBA: Nameserver) - andere nach Wunsch dazu (NFS, Sockets,
...)
- Translators: Mountpunkte, symbolische Links, Devices
- jede Datei hat einen Translator
- FTP-Translator, Datenbank, ...
- Umgebung, in der eine Ausführung stattfinden kann: Adreßraum
(Programmtext, Daten, Stacks) - Basiseinheit für Zuteilung von
Betriebsmitteln
- passiv - Ausführung an Threads gebunden, Container für Threads
- jede Task hat bestimmte Ports: Prozeß-Port (Kommunikation mit Kernel -
Systemaufrufe), Bootstrap-Port (Initialisierung), Exception
(Fehlermeldungen - Debugger!), registrierte Ports (Komm. mit
Standard-System-Servern)
- Prozesse können rechenbereit oder wartend sein - unabhängig von Threads!
- Scheduling-Parameter (SMP)
- besitzt, anders als Unix-Prozesse, keine uid, gid, Wurzel- und
Arbeitsverzeichnis, kein Feld von Dateideskriptoren
- ausführbare Einheit (Programmzähler, Register) - gehört zu genau einem
Prozeß
- alle Prozesse eines Threads benutzen den Adreßraum des Threads gemeinsam
- jeder Thread eigenen Thread-Port (Systemaufrufe, wie Beenden)
- können auf Ports der Geschwister zugreifen - Kontrolle!
- bei SMP mehrere gleichzeitig aktiv - Synchronisation, Scheduling
- lauffähig / blockiert
- C-Threads Paker: API zu Kernel (fork, exit, join, yield, detach)
- Zuordnung Threads / Prozesse:
- alle C-Threads in einem Kernel-Thread - ein Thread blockiert ganzen
Prozess
- ein Mach-Thread pro Kernel-Thread (auch m zu n)
- ein Thread pro Prozess - Ressourcen (Ports, File Handles) teilen
unmöglich
- beliebig viele User-Threads auf beliebig viele Kernel-Threads - am
flexibelsten, aktuell
- Speicherobjekt: Datenstruktur, im Adreßraum eines Prozesses abgebildet
- Basis für Verwaltung des virtuellen Speichers
- maschinenunabhängigen Teile der Speicherverwaltung klar getrennt von
maschinenabhängigen - Portabilität!
- Speicherverwalter (externer Pager) = Benutzerprozeß - logische
Verwaltung
- Benutzer können eigene schreiben
- Prozesse können Speicherobjekte gemeinsam benutzen (SMP!)
- bei Erzeugen von Kindsprozessen: zunächst als read-only geteilt, bei
Schreiben des Kindes kopiert (copy-on-write)
- externer Pager: zum Mappen 3 Ports - Objekt-Port (Pager - Info),
Kontroll-Port (Kernel - Ereignisantwort), Namens-Port (Kernel - Nachfragen
anderer)
- Paging-Dämon - überprüft regelmäßig den Zustand des Speichers und
veranlaßt externe Pager zum Swappen
- geschützter Briefkasten für Prozesse
- speichert geordnete Liste von Nachrichten
- wie Pipes in Unix - unidirektionale Kommunikation
- Nachrichten gehen garantiert nicht verloren und kommen in der richtigen
Reihenfolge an
- nicht als Byte-Ströme - strenge Grenzen zwischen Nachrichten
- Nachrichten extra als Nachrichtenschlange gespeichert
- in Portgruppen zusammenfassen - nur lesend
- einfache oder komplexe Nachrichten
- komplexe Nachrichten: Folge von Deskriptor-Datenfeld-Paaren
- out-of-line-Daten: Daten ohne zu kopieren übertragen
- Ports in komplexe Nachrichten verpacken
- Unix Emulator als Server auf Mach
- Unix Server, Systemfunktionsemulationsbibliothek
- Unix Server an Kernel: trap Systemaufruf und schicke an
Emulationsbibliothek (Trampolin)
- Emulationsbibliothek: RPC an Unix Server zum Arbeiten
- Unix Server mit C-Threads implementiert
- I/O Aufrufe anders: Performance
- Datei öffnen ohne RPC - direkt von Emulationsbibliothek
- eigenen Memory Manager (Inode-Pager)
- kopiert Dateien in Applikationsspeicher um - Synchronisation bei
gleichzeitigem Zugriff auf eine Datei
- klingt alles langsam, ist es aber nicht
- demnaechst Unix-Server aufsplitten?
- Dateisystem: hierarchisch geordnete Dateien und Ordner
- mit Pfad beschrieben
- außerdem harte und weiche Links, Devices, FIFOs
- viele gleiche Eigenschaften: Besitzer, Gruppe, Zugriffsrechte - alles in
Inodes
- alle Inodes mit read() und write() lesen
- im HURD anders: Translator zwischen Datei / Inode und Benutzer, der
darauf zugreift
- Angaben über Translators in der Inode gespeichert - mit User-Rechten
darauf zugreifen (Translotor-UID = Owner des Files)
- Mount-Points = Inode mit besonderem Translator
- Devices, Symbolic Links
- aktive und passive Translators
- passive werden erst bei Zugriff gestartet (
modprobe)
- Programme settrans, showtrans
- mount sollte theoretisch ein Shell-Skript sein (ist aber nicht)
- damit Komplexität von ftp, tar, gzip, XDisplays verstecken...
- Servers sind Translatoren
- werden in .def-Dateien definiert
- GNU-C-Library verwendet für Unix System Calls
- Netzwerk auch mit Translator: pfinet (passiv)
- jedes Programm als Translator!
- Authentication-Server: RPC, Schnittmenge von 2 Authentication Ports
- auch wenn User Authentication-Server schreiben - Programme reden mit
denen, denen sie vertrauen - wenn nicht der gleiche, nix Auth.
- deshalb bloss ein Auth-Server - aber extra Passwort-Server
- Process-Server: uname -a, POSIX, Mach tasks
HURD Prozesse, PIDs,
Message Ports registrieren
- verschiedene Prozess-Server...
- gibt auch crash-server (bei segfault): suspend / kill / core dump
- exec-server: aus image file den Prozess herstellen (boot-floppies)
- fifo-server, firmlink (zw. symlink und hard link), ftpfs, fwd (zum
forwarden an andere Server: fifos), init, isofs, magiv, nfs, null, pflocal
(für pipes), symlink, term, ...
Aufwärts: hurd
Vorherige Seite: Das HURD-System
Britta Koch