Hurd - Der Kernel-Ersatz von GNU

Dieser Text fasst den auf dem LinuxTag 2002 in Karlsruhe gegebenen Vortrag zu Hurd zusammen.

Was ist Hurd?

Hurd ist - wie der Titel dieses Vortrages andeutet - kein Kernel, sondern ein Kernel-Ersatz. Es handelt sich bei Hurd um eine Sammlung von Daemonen (auch als "Server" bezeichnet), die auf dem Mach Mikrokernel laufen und gemeinsam mit der GNU C Bibliothek (glibc) die Funktionalität eines Unix-Kernels bereitstellen, bis auf die wenigen Aspekte, die bereits von Mach angeboten werden. Damit ist das Hurd-basierte GNU-System ein POSIX-konformes Betriebssystem.

An dieser Stelle einige Worte zur Terminologie: Es wird unterschieden zwischen GNU Hurd, oder einfach nur Hurd, und dem vollständigen, Hurd-basierten GNU-System, welches als GNU/Hurd bezeichnet wird. Es gibt zwar auch andere Varianten von GNU, nämlich das Linux-basierte GNU-System und eines, das auf einem nicht-freien Kernel aufsetzt, doch wenn von "dem GNU-System" oder einfach nur "GNU" gesprochen wird, ist üblicherweise GNU/Hurd gemeint.

Hurd

Bestandteile von Hurd

Im Detail funktioniert das folgendermaßen: Applikationen aus der Unix-Welt, hier als POSIX-Applikationen bezeichnet, nutzen die C Bibliothek für Unix-Systemrufe. Die glibc implementiert entsprechende Funktionen und nutzt dabei die Dienste der Hurd-Server und teilweise auch des Mach Kernels. Die Hurd-Server wiederum nutzen auch Funktionen aus der glibc, da es sich prinzipiell um gewöhnliche Prozesse bzw. Daemonen handelt. Diese nutzen dabei ebenfalls Dienste von Mach. Denkbar sind natürlich auch Programme, die direkt mit den Hurd-Servern kommunizieren. Solche Programme sollten aber eher die Minderheit stellen, da in der Regel POSIX-Konformität sinnvoll ist. (Zumindest, solange es noch andere Betriebssysteme gibt.)

In diesem Zusammenhang möchte ich aber schon einmal vorwegnehmen, dass die meisten Programme nicht an die besonderen Fähigkeiten von Hurd angepasst werden müssen, um von diesen profitieren zu können, da diese überwiegend transparent angeboten werden. Das bedeutet, dass auch die ganzen POSIX-Applikationen mächtiger werden.

Die POSIX-Konformität ist wohl einer der entscheidenden Punkte, in denen sich das GNU-System von anderen Multiserver-Mikrokernelsystemen unterscheidet. Das schönste System nutzt schließlich nichts, wenn es keine Applikationen dafür gibt. Eine abschließende Bemerkung zu dem Thema sei gestattet, da es ein häufiges Missverständnis ist: Oft wird behauptet, selbst das proprietäre System Microsoft Windows NT sei POSIX-konform. Tatsächlich implementiert es zwar die POSIX-Systemrufe, aber POSIX umfasst weit mehr als nur diese.

Geschichte und Motivation des Hurd-Projektes

Hurd ist ein Teil des GNU-Projektes. GNU wurde in den 80er Jahren von Richard Matthew Stallman mit der Zielsetzung ins Leben gerufen, ein vollständiges Betriebssystem zu erschaffen, das ausschließlich aus Freier Software besteht. Dabei wurden bereits als Freie Software existierende Komponenten verwendet, sofern diese vorhanden waren, etwa das X11 Fenstersystem oder TeX. Hier kann man sich also ernsthaft die Frage stellen, warum Hurd entwickelt wird, obwohl mit Linux eine ausgreifte Basis für das GNU-System existiert.

Die Antwort darauf ist sehr einfach: Hätte Linux bereits existiert (und wäre dabei noch einigermaßen portabel gewesen, denn das war Linux zu Beginn nicht), als die Free Software Foundation mit der Entwicklung von Hurd begann, hätte man wohl in der Tat den Kernel Linux verwendet. Und tatsächlich hatte die Free Software Foundation wenig Interesse daran, bei Null zu beginnen, und hat daher den bereits exitierenden Mach Mikrokernel als Basis genutzt. Nachdem es durch Linux allerdings möglich wurde, einen Computer zu benutzen, ohne proprietäre Software einzusetzen, hatte die Weiterentwicklung von Hurd keine hohe Priorität mehr, zwischenzeitlich stand die Entwicklung sogar praktisch still.

Dies ist allerdings keineswegs der einzige Grund, wegen dem Hurd erst auf dem jetzigen Stand der Entwicklung ist, während das Linux-basierte GNU-System bereits in einer etwas höheren Liga spielt. Ein weiterer wichtiger Grund dafür ist, dass Hurd mit dem gleichen Ziel entwickelt wurde wie die übrige GNU-Software: Besser zu sein als das jeweilige Äquivalent der Unix-Welt.

Viele Unix-Programme tragen willkürliche Einschränkungen in sich, etwa werden von manchen Tools lange Eingabezeilen stillschweigend nach einer bestimmten Anzahl Zeichen abgeschnitten. So etwas war für GNU niemals akzeptabel. Der Ehrgeiz, es besser zu machen, führte zu Programmen, die tatsächlich flexibler und leistungsfähiger waren als entsprechende Unix-Werkzeuge. In gleicher Weise sollte Hurd den Unix-Kernel übertreffen, also seine Einschränkungen vermeiden.

Was aber sind nun die Einschränkungen des Unix-Kernels? In erster Linie sind es solche, die vergleichbar mit denen aus angestaubten Unix-Programmen sind. Ein typisches Beispiel wäre die Beschränkung auf die Länge von Pfadnamen. Doch dies ist keineswegs das größte Problem. Weitaus unangenehmer ist in der Praxis die monolitische Natur des Kernels. Bei näherer Betrachtung zeigt sich nämlich, dass der Unix-Kernel in keiner Weise die Unix-Philosophie wiederspiegelt, denn diese propagiert beispielsweise kleine Programme, die genau eine Aufgabe erfüllen. Der Kernel hingegen enthält neben Hardware-Treibern auch Treiber für Dinge wie Dateisysteme und Netzwerkprotokolle, bei denen es keinen Grund gibt, sie im Kernel zu haben. Man mag als Grund hier natürlich die Geschwindigkeit anführen, und in der Tat war der TCP/IP Stack immer als externe Komponente konzipiert, bis er dann aus Performancegründen in den Kernel verlegt wurde. Doch selbst unter der Annahme, dass das Argument der höheren Geschwindigkeit auch heute noch gültig sei, würde man damit zugeben, dass man hier auf einmal nicht mehr der Unix-Philosophie folgt, denn diese hat Geschwindigkeit immer geringer geschätzt als beispielsweise Aspekte der Wartbarkeit.

Warum passt der Unix-Kernel aber nicht so recht zum Rest des Systems? Es liegt gewiss nicht daran, dass die Erfinder von Unix unfähig waren, im Gegenteil: Unix ist sicherlich ein geniales Stück Technologie, das sich aus guten Gründen bis heute gehalten hat. Allerdings waren die Rechner, auf denen Unix ursprünglich lief, kaum mit den heutigen vergleichbar. Der Kompromiss, den Unix-Kernel anders zu gestalten als den Rest des Systems, war einfach eine Notwendigkeit. Und genau das ist es, was das GNU-System - aus technischer Sicht - von Unix unterscheidet: Es wird angenommen, dass ein solcher Kompromiss heute nicht mehr nötig ist und sogar mehr schadet, als er nützt.

Anders gesagt: Es ist schon schlimm genug, dass uns durch Hardware Grenzen gesetzt werden. Daher sollten wir keine zusätzlichen in die Software einbauen.