Im User-Space arbeiten

Ein Unix-Programmierer, der sich zum erstenmal mit dem Kernel beschäftigt, ist jetzt vielleicht etwas nervös, wenn er ein Modul schreiben soll. Das Schreiben eines Benutzerprogramms, das die Geräte-Ports direkt ausliest und beschreibt, ist viel einfacher.

Tatsächlich gibt es einige Argumente für die Programmierung im User Space, und mitunter ist das Schreiben von sogenannten User Space-Gerätetreibern eine sinnvolle Alternative zum Kernel-Hacken.

Die Vorteile von User-Space-Treibern können folgendermaßen zusammengefaßt werden:

ark=dash>

Ein Beispiel eines User-Space-Treibers ist der X-Server: Er weiß genau, was die Hardware kann und was nicht, und bietet diese grafischen Ressourcen allen X-Clients an. Beachten Sie aber, daß es eine langsame, aber stetige Bewegung hin zu Framebuffer-basierten Grafikumgebungen gibt, in denen der X-Server nur als Server, der auf einem echten Kernel-Space-Gerätetreiber für die Grafikmanipulation basiert, arbeitet.

Üblicherweise implementiert ein User-Space-Treiber einen Server-Prozeß, der vom Kernel die Aufgabe übernimmt, das einzige Stück Code zu sein, das die Hardware kontrolliert. Client-Applikationen können sich dann mit diesem Server verbinden, um mit dem Gerät zu kommunizieren; ein intelligenter Treiber-Prozeß kann also auch nebenläufigen Zugriff auf das Gerät ermöglichen. Genau so funktioniert auch der X-Server.

Ein anderes Beispiel für einen User-Space-Treiber ist der Maus-Server gpm: Er weist die Maus verschiedenen Clients zu und vermittelt zwischen diesen, so daß diverse maussensitive Applikationen auf verschiedenen virtuellen Konsolen laufen können.

Manchmal gewährt ein User-Space-Treiber aber auch nur einem einzigen Programm Zugriff auf das Gerät. So funktioniert beispielsweise libsvga. Diese Bibliothek, die die grafische Ausgabe auf einem Terminal ermöglicht, wird zur Applikation hinzugelinkt und bietet der Applikation so den Zugriff auf den Bildschirm, ohne daß diese sich noch an eine zentrale Autorität (d.h. einen Server) wenden muß. Dieser Ansatz führt normalerweise zu besserer Performance, weil der Kommunikations-Overhead entfällt, verlangt aber, daß die Anwendung als privilegierter Benutzer läuft (dieses Problem wird unter anderem durch die Verwendung eines Framebuffer-Gerätetreibers im Kernel-Space gelöst).

Der User-Space-Ansatz hat aber auch eine Reihe von Nachteilen. Die wichtigsten sind:

ark=dash>

Wie Sie sehen, können User-Space-Treiber nicht viel machen. Trotzdem gibt es aber interessante Anwendungen, beispielsweise Unterstützung für SCSI-Scanner (im SANE-Paket implementiert) und CD-Brenner (implementiert durch cdrecord und andere Programme). In beiden Fällen verwenden die User-Space-Gerätetreiber den “generischen SCSI-Kernel-Treiber”, der die SCSI-Funktionalität niedriger Ebene den User-Space-Programmen zur Verfügung stellt, so daß diese auf ihre Hardware zugreifen können.

Um einen User-Space-Treiber zu schreiben, genügen mittlere Hardware-Kenntnisse, und man muß die Subtilitäten der Kernel-Programmierung nicht verstehen. Wir werden in diesem Buch nicht weiter auf Treiber im User-Space eingehen, sondern uns auf Kernel-Code konzentrieren.

Wenn Sie es dagegen mit ungewöhnlicher Hardware zu tun haben, dann kann es sinnvoll sein, die Software erst einmal im User-Space zu schreiben. Auf diese Art und Weise können Sie Ihre Hardware kennenlernen, ohne zu riskieren, daß das ganze System hängenbleibt. Wenn Sie das einmal geschafft haben, dann sollte es nicht mehr weiter schwierig sein, die Software in ein Kernel-Modul zu kapseln.

Fußnoten

[1]

Dieser Systemaufruf wird in diesem Buch nicht besprochen, da es uns hier vor allem um Kernel-Treiber geht; außerdem ist vm86 zu plattformspezifisch, um wirklich interessant zu sein.