Hurd - Der Kernel-Ersatz von GNU

Aufbau eines Hurd-Systems

Nachdem am Anfang bereits ein kurzer Überblick über die generelle Architektur gegeben wurde, soll hier vertieft werden, wie die einzelnen Komponenten zusammenarbeiten. Ein System, das sich vom Aufbau her so grundlegend von traditionellen Systemen unterscheidet, besitzt natürlich seine eigene Terminologie, d.h. neben dem Mikrokernel-Jargon gibt es zusätzlich auch einen eigenen Hurd-Jargon, weshalb im Folgenden eine ganze Reihe neuer Begriffe eingeführt wird. Außerdem wird es jetzt vorübergehend ein wenig theoretisch, doch ich werde bald darauf zurückkommen, was all dies für den Benutzer bedeutet.

Ein Hurd-Server bietet einen Dienst an - das ist naheliegend. Da ein solcher Server ein Prozess ist, verwenden andere Prozesse, die seine Dienste in Anspruch nehmen wollen, IPC (Inter Process Communication bzw. im Deutschen "Interprozesskommunikation"), um mit ihm zu kommunizieren - auch das überrascht nicht. In Mikrokernelsystemen ist die wichtigste Art der IPC das sogenannte "Message-Passing", also das Übergeben von Nachrichten. Eine solche Nachricht wird über einen "Port" übergeben, d.h. der Client sendet eine Nachricht an den Port, der Server empfängt sie von dort. Ein Port ist also sozusagen eine Nachrichten-Warteschlange und ein Client sendet Anfragen in Form von Nachrichten über einen Port an den Server. In der Praxis wird dann der Mach Interface Generator (MiG) verwendet, um sogenannten Stub-Code zu erzeugen, durch den das Senden einer bestimmten Nachricht in Form eines einfachen Funktionsaufrufes durchgeführt wird. Dies bezeichnet man als "Remote Procedure Calls" (RPCs).

Hurd

Client-Server-Architektur

Nun ist aber noch die Frage offen geblieben, wie ein Client denn an einen Port herankommen kann. Was müsste also z.B. ein Programm tun, um den Password-Server zu kontaktieren, der im Austausch gegen eine User-ID und das entsprechende Passwort ein passendes Authentifikationstoken herausrückt (was das genau bedeutet, werden wir später sehen)? Die Antwort lautet: Er muss das gleiche tun, was ein Prozess tun muss, um eine Datei zu öffnen, wenn er im Austausch auf eine Lese-Anforderung entsprechende Daten erhalten will. D.h. während traditionelle Multiserver einen zentralen "Telefonbuch-Server" haben, der einem Client den Port liefert, der einer bestimmten Bezeichnung entspricht, gibt es bei Hurd eine Reihe solcher Telefonbücher - nämlich die Dateisystem-Server - die hierarchisch angeordnet sind.

Neben dem Dateisystem gibt es noch weitere Möglichkeiten, an einen Port zu kommen, etwa kann ein Port auch in einer versendeten Nachricht übergeben werden, z.B. um eine Antwort auf eine Nachricht schicken zu können.

Das bedeutet erstens, dass jeder Benutzer seine eigenen Dateisysteme bzw. Dateisystem-Erweiterungen in den Teilen des Verzeichnisbaumes platzieren kann, über die er die Kontrolle hat. Wir bezeichnen diese Server als Übersetzer bzw. Translatoren. Im Hurd-basierten GNU-System kann also jeder Benutzer innerhalb seines Heimverzeichnisses eigene Dateisysteme verwenden, wenn er das will. Was unter GNU/Linux als Loopback-Mounten bekannt ist, kann hier völlig problemlos jedem gestattet werden, da ein dafür verwendeter ext2-Server (oder ein beliebiger anderer) mit den Berechtigungen des Benutzers läuft, der ihn gestartet hat und somit dem System nicht mehr Schaden zufügen kann als jeder andere Prozess auch.

Zusätzlich sind aber ebenso rein virtuelle Dateisysteme denkbar, prinzipiell vergleichbar mit devfs oder dem /proc Dateisystem unter GNU/Linux, mit dem Unterschied, dass diese hier als gewöhnliche Programme laufen würden, was interessante Lösungen für verschiedendste Problemstellungen ermöglicht. So existiert z.B. ein Übersetzer, dem man als Argument beim Starten eine Kommandozeile übergibt. Wenn jemand die von ihm bereitgestellte Datei öffnet, führt er das betreffende Kommando aus. Wenn nun derjenige, der die Datei geöffnet hat, daraus lesen will, bekommt er die Daten, die das vom Übersetzer gestartete Programm an seine Standardausgabe geschrieben hat. Diesen Übersetzer könnte man z.B. auf seiner ~/.signature platzieren und ihn jedes mal ein Fortune-Cookie zurückliefern lassen, wenn ein E-Mail-Client ihn öffnet, um die Signatur auszulesen.

Zweitens bewirkt das Konzept der Übersetzer, dass neben Dateisystemen auch beliebige andere Dienste über das Dateisystem angeboten werden können. Ein typisches Beispiel hierfür ist der oben erwähnte Password-Server, ein anderes wäre die Socket-Schnittstelle. Ermöglicht werden dadurch auch völlig neue Ansätze, etwa ist eine grafische Benutzeroberfläche - oder auch nur ein X11-Toolkit - denkbar, das neben der Bildschirmausgabe auch noch alle Widgets und Fenster im Dateisystem darstellt, wodurch Aktionen nicht nur vom Benutzer durchgeführt werden können, sondern auch von Programmen. Das wäre nicht zuletzt zum automatisierten Testen von GUI-Applikationen interessant.

Denken Sie bei Gelegenheit einmal darüber nach, was durch Übersetzer alles realisierbar ist. Ich bin sicher, dass Ihnen eine Menge interessanter Dinge einfallen werden, an die noch keiner vor Ihnen gedacht hat.

Die Tatsache, dass es sich bei fast allen Komponenten um gewöhnliche Prozesse handelt, bedeutet auch, dass jeder Benutzer seinen eigenen Hurd starten kann, also einen "Neighborhurd". Damit kann er praktisch sämtliche Server durch seine eigenen Implementierungen ersetzen. Da diese Prozesse in einem separaten Hurd laufen, können sie außerhalb keinen Schaden anrichten. Sie können noch nicht einmal die außerhalb laufenden Prozesse sehen, allerdings sind alle Prozesse des Neighborhurds über den Haupt proc-Server des Systems sichtbar, damit der Administrator auch über diese Prozesse Kontrolle hat.