© pixelquelle.de

Seit Ende Juni ist Dev-FS nun endlich Geschichte: Nachdem es mehr als drei Jahre auf dem Abstellgleis rangierte, verdrängte sein Nachfolger Udev den Geräteverwalter jetzt endgültig aus dem Kernel. Das Linux-Magazin blickt dem Sieger unter die Haube.

Vom guten alten Unix hat Linux das Prinzip geerbt: Alles ist eine Datei. Diese Abstraktion erlaubt es den Programmen, auf angeschlossene Hardware über so genannte Devicenodes (Gerätedateien) genauso zuzugreifen wie auf gewöhnliche Files. Die Spezialdateien lassen sich über dieselben Systemaufrufe öffnen, lesen, schreiben oder schließen.

Untereinander unterscheiden sie sich durch ihren Namen, ihren Typ (Block- oder Zeichengerät) und ihre Major- sowie Minor-Nummer. So repräsentiert auf einem Linux-System zum Beispiel der Devicenode »/dev/hda1« die erste Partition der Festplatte »/dev/hda« und trägt dabei die Major-Nummer 3 und die Minor-Nummer 1.

Der Befehl »mknod« legt die Gerätedateien an. Bei traditioneller Verwaltung dieser Files geschieht dies während der Installation. Das Verzeichnis »/dev« enthält danach für alle Zeit einen Eintrag für jedes Gerät, das der Admin möglicherweise später einmal dem System hinzufügen möchte – und das können gut einige tausend sein.

Statisch ist nicht übersichtlich

Allerdings leidet die Übersichtlichkeit unter der Fülle an Einträgen, die zudem für den konkreten Rechner größtenteils unnötig sind, weil er nie mit den passenden Geräten in Kontakt kommt. Darüber hinaus gibt es weitere Nachteile. So spiegelt die Verzeichnis- und Dateistruktur nicht wider, welche Geräte tatsächlich vorhanden sind oder korrekt von Treibern erkannt wurden.

Außerdem bestimmt bei diesem herkömmlichen Ansatz die Reihenfolge, in der ein Benutzer Geräte anschließt, zugleich auch darüber, welches Gerät der Kernel welcher Gerätedatei zuordnet. Die erste erkannte SCSI-Platte bildet sich so beispielsweise immer auf das Devicefile »/dev/sda« ab, die nächste, danach angesteckte auf »/dev/sdb« und so fort. Das kann dazu führen, dass ein und dasselbe Gerät zu verschiedenen Zeiten über mehrere Gerätedateien erreichbar ist und der Rechner es folglich an verschiedene Verzeichnisse mountet.

Besser bei Bedarf

Als viel bessere Lösung erweist sich daher eine Verfahrensweise, bei der das System Gerätedateien erst in dem Moment anlegt oder löscht, in dem der Benutzer Hardware hinzufügt beziehungsweise entfernt. Über die Zuordnung von Namen zu Devices entscheiden hier Regeln anstelle der Reihenfolge. So kann man etwa garantieren, dass eine bestimmte Festplatte immer über dasselbe File zu erreichen ist und sich immer an derselben Stelle ins Filesystem einbindet – ganz egal welche anderen Geräte zu welchem Zeitpunkt den Bus mitbenutzten oder nicht.

Sieger Udev

Eine Zeit lang konkurrierten die Systeme Dev-FS und Udev um die Rolle des intelligenten Geräteverwalters. Inzwischen gibt es einen Gewinner: Dev-FS flog kürzlich endgültig aus dem Kernel, der klare Sieger heißt Udev [1]. Es setzt den schon seit längerem im Kernel eingerichteten Hotplug-Mechanismus (siehe Kasten “Hotplug im Detail”) ein, um im Userspace nach Bedarf Gerätedateien anzulegen.

Wird ein Gerät angeschlossen oder entfernt, signalisiert der Controller des jeweiligen Busses (ISA, USB, PCI) dies durch einen Interrupt. Als Reaktion auf diese Unterbrechung ermittelt der Kernel Details über das frisch hinzugekommenen Device, indem er entweder den Hardware-Controller nach Einzelheiten befragt oder an fest vorgegebenen Adressen – beispielsweise im Konfigurationsbereich von PCI-Karten – nach dort abgelegten Informationen fahndet, insbesondere nach der Vendor- und der Product-ID des neuen Geräts.

Anschließend legt er für den Neuankömmling ein so genanntes Kobject an, das die Verwaltungsinformationen aufnimmt, wobei er die Informationen über den Gerätetyp (Char- oder Blockdevice) und die Major- und Minor-Nummer über den mit Kernel 2.6 eingeführten globalen Namensraum für Kernelkomponenten erhält (vergleiche auch Kasten “Hotplug im Detail”). Diese Informationen macht der Kernel dann seinerseits über das Sys-FS [2], das in diesem Punkt das alte Proc-FS ablöst, auch anderen zugänglich. Sys-FS wird normalerweise nach »/sys« gemountet.

Staffellauf

Um Usermode-Programme über den neuen Gerätestatus zu informieren, ruft der Kernel danach bei älteren Udev-Versionen das in »/proc/sys/kernel/hotplug« eingetragene Programm auf. Meist heißt es »/sbin/hotplug«. Es kann beispielsweise nötige Treiber laden und konfigurieren. Welche das sein müssen, ermittelt es anhand der erwähnten IDs. Moderne Udev-Versionen kommunizieren direkt mit dem Kernel und stoßen dieselben Aktionen ohne Umweg an. Dann entfällt das Skript ersatzlos.

RUN+="socket:/org/freedesktop/hal/udev_event"

So verfährt Udev nicht nur beim Hinzufügen neuer Geräte im laufenden Betrieb (Hotplugging), sondern ebenso bei der ersten Initialisierung während des Bootens (Coldplugging). Dabei sucht der Kernel zunächst die Busse nach Geräten ab und erzeugt anhand des Suchergebnisses Dateien mit dem Namen »uevent«, die er – weil beim Booten anfänglich kein beschreibbares Root-Dateisystem vorhanden ist – im virtuellen Sys-FS ablegt. Später generiert Udev anhand dieser Files für jedes beim Booten gefundene Gerät einen Event.

Von hier an gleichen die Abläufe haargenau denen beim späteren Anschließen der Devices zur Laufzeit. Abbildung 1 zeigt ein mit dem Diagnose-Tool »udevmonitor« erzeugtes Protokoll, das die Geschehnisse beim Einstecken eines USB-DVB-Empfängers aufführt.

Abbildung 1: Die Aktionen von Udev während des Hotplugging zeichnet das Tool »udevmonitor« auf, hier protokolliert es, was beim Anstecken eines USB-DVB-Empfängers passiert.

Bis zur Udev-Version 0.58 lädt das Hotplug-Paket Treiber und Firmware, so bei den Suse-Versionen 9.x, bei Fedora Core 4, Ubuntu Breezy Badger und Debian Sarge. Dabei bleibt »/sbin/hotplug« der Hotplug-Manager und ruft nach getaner Arbeit als Multiplexer alle in »/etc/hotplug.d« eingetragenen Programme auf. Bei einer Standardinstallation der Hotplug- und Udev-Pakete sollten diese korrekt zusammenarbeiten. Ab 0.59 übernimmt Udev beide Aufgaben, etwa bei Fedora Core 5, Suse 10 und Ubuntu Dapper Drake (siehe Tabelle 1).

Abbildung 2: Hinter den Kulissen des Gnome Volume Manager arbeiten Udev, HAL und D-Bus zusammen. Hier das Frontend»gnome-volume-manager-properties«, mit dem Reiter, der das Verhalten beim Anschluss von Wechselfestplatten regelt.

01 <deviceinfo version="0.2">
02   <device>
03     <match key="info.bus" string="usb">
04       <match key="usb.interface.class" int="0x06">
05         <match key="usb.interface.subclass" int="0x01">
06           <match key="usb.interface.protocol" int="0x01">
07             <merge key="info.category" type="string">camera</merge>
08             <append key="info.capabilities" type="strlist">camera</append>
09             <merge key="camera.access_method" type="string">ptp</merge>
10           </match>
11         </match>
12       </match>
13     </match>
14   </device>
15 </deviceinfo>

Einstellungssache

Die Udev-Konfigurationsdateien befinden sich im Verzeichnis »/etc/udev«, bei einigen Distributionen auch in »/lib/udev«. Die wichtigsten Variablen für generelle Einstellungen stehen in der Datei »/etc/udev.conf«. Sie speichern zum Beispiel das Wurzelverzeichnis der Gerätedateien, den Ort der internen Udev-Datenbank, das Verzeichnis der Regeln für das Anlegen und Benennen der Gerätedateien und den Logging-Level:

udev_root="/dev/"
udev_db="/dev/.udevdb"
udev_rules="/etc/udev/rules.d"
udev_log="err"

Für die Konfiguration seiner Funktionsweise bietet Udev zwei weitere Eingriffspunkte: In »/etc/udev/rules.d/« befinden sich Dateien, die regeln, wie die Devicenodes zu benennen sind, die Udev bei Bedarf erzeugt. In »/etc/udev/makedev.d/« liegen Skripte mit den Namen der statischen Gerätedateien, die zum Beispiel für die alte Parallelschnittstelle nötig sind. Bei manchen Distributionen fehlt dieses File. Die Zugriffsrechte stehen bei aktuellen Udev-Versionen nicht mehr wie früher im Verzeichnis »/etc/udev/permissions.d«, sondern in der normalen Udev-Konfiguration.

Abbildung 3: Der HAL Device Manager zeigt die Hardware in Baumform an. Die Zusatzinformationen zu jedem Gerät gehen ziemlich ins Detail. Hier die einer an USB angeschlossenen digitalen Kamera.

Regelsyntax

Der erste Teil jeder Regel gibt jene Bedingung an, die erfüllt sein muss, damit Udev den zweiten Teil ausführt beziehungsweise anwendet. Im einfachsten Fall muss nur der Kernel-interne Name eines Geräts oder eines Subsystems zutreffen. Für eine Tastatur lautet die Bedingung beispielsweise »KERNEL==”kbd”«.

Die Bedingungen sind wie bei einer Programmiersprache mit doppelten Gleichzeichen gekennzeichnet. Nach einem Komma können weitere Bedingungen folgen. Die auszuführenden Aktionen enthalten dagegen nur ein einfaches Gleichzeichen. So setzt zum Beispiel der Ausdruck »MODE=”0660″« die Zugriffsrechte. Analog lassen sich mit »OWNER« der Eigentümer oder mit »GROUP« die Gruppe spezifizieren, die eine Gerätedatei zugeordnet bekommt.

Ihren Namen gibt das Schlüsselwort »NAME« vor, das einige Platzhalter verarbeitet. So steht etwa »%k« für den oben vorgestellten Kernelnamen. Eine Regel nach diesem Muster könnte zum Beispiel so aussehen: »KERNEL==”isdn*”, NAME=”%k”, MODE=”0660″«. In diesem Fall wird für jedes Gerät, dessen Kernelname mit »isdn« beginnt, ein Devicenode gleichen Namens mit Lese- und Schreibrechten für den Eigentümer und seine Gruppe angelegt.

Normalerweise geht Udev alle zutreffenden Regeln durch, bis keine weiteren vorhanden sind. Um die Verarbeitung nach dem Zutreffen einer Regel abzubrechen, ist unter »OPTIONS« die Anweisung »last_rule« anzugeben.

Probe-Skripte

Die Udev-Regeln können auch externe Programmaufrufe enthalten, die ebenfalls als Bedingung gelten. Nur wenn der Aufruf das gewünschte Ergebnis liefert, führt Udev die anschließend aufgeführten Aktionen aus. Die Manpage enthält ein Beispiel für Atapi-CD-ROMS, das untersucht, ob ein entsprechendes »/proc«-Verzeichnis vorhanden ist, das ein Gerät als CD-ROM identifiziert:

KERNEL=="hd[a-z]", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom", NAME="%k", SYMLINK="cdrom%e"

Hierbei gibt Udev für alle Geräte, deren Name mit »hd« beginnt, mit »/bin/cat« den Inhalt der entsprechenden »media«-Datei aus. Wenn sie »cdrom« enthält (»RESULT«), behält Udev die Gerätedatei bei (»NAME=”%k”«), legt aber zusätzlich mit »SYMLINK« einen symbolischen Link »cdrom« an. Das »%e« spezifiziert die nächste freie Dezimalzahl, falls eine gleichnamige Datei schon vorhanden ist, So entstehen symbolische Links:

/dev/cdrom -> hdc
/dev/cdrom1 -> sr0

Wertet man mit Hilfe einer Udev-Regel die eindeutige Seriennummer eines angeschlossenen Geräts aus, dann lassen sich auf diesem Wege auch für Hotplug-Geräte stabile Namen erreichen, die unabhängig von der Anschluss- oder Einschaltreihenfolge sind. Ein Beispiel für eine solche Regel könnte wie folgt aussehen:

BUS=="usb", SYSFS_serial=="W09090207101241330", NAME="lp-kyocera"

Damit erhält der eingesteckte Drucker mit der zutreffenden Seriennummer stets den Gerätenamen »lp-kyocera«.

Die häufigsten Anwendungen für selbst geschriebene oder von Benutzern geänderte Udev-Regeln sind wohl individuell angepasste Gerätenamen oder spezielle Rechte für Devicefiles. Zum Beispiel soll der auf dem Desktop eingeloggte Benutzer auf zur Laufzeit hinzugefügte USB-Festplatten schreiben dürfen. Fedora löst dieses Problem recht elegant dadurch, dass Udev deren Gerätedateien einfach dem auf dem Desktop eingeloggten Benutzer übereignet.

01 <?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
02 <!-- This .fdi file prevent automount for every media (storage devices)
03     e.g. floppy, CD/DVD, USB-Stick, USB-Disk, external harddisk. -->
04 <deviceinfo version="0.2">
05    <device>
06       <match key="storage.policy.should_mount" bool="true">
07          <merge key="storage.policy.should_mount" type="bool">false</merge>
08       </match>
09    </device>
10 </deviceinfo>

D-Bus

D-Bus fungiert als Kommunikationssystem, das Desktop-Anwendungen untereinander und mit den darunter liegenden Schichten bis hin zu Kernel und Hardware verbindet. Er steht also im Dienst der Interprozesskommunikation (Inter Process Communication, IPC) und stellt die Infrastruktur bereit, dank der sich Anwendungen untereinander und mit Teilen des Betriebssystems unterhalten können. Zwar gibt es schon von Anfang an die bewährten Unix-IPC-Mechanismen, doch die beschränken sich auf Signale, Pipes und so fort. Babel der Kommunikation Das D-Bus-Konzept klingt bekannt, denn schon seit langem gibt es konkurrierende Ansätze, zum Beispiel Corba, Microsofts DCOM und noch hundert weitere Projekte. Sowohl KDE als auch Gnome haben zu Beginn mit eigenen Corba-Implementierungen experimentiert. KDE setzt seit längerem auf das Eigengewächs DCOP, bei Gnome wirken die Corba-Altlasten noch in dem Komponentensystem Bonobo nach. Nun kann man zu Corba stehen, wie man will, die meisten Entwickler, die nur eben mal eine Desktop-Anwendung programmieren möchten, sind damit überfordert. Selbst einfache Gnome-Applets setzen die eingehende Beschäftigung mit der komplizierten Komponenten-Architektur voraus. Entsprechend fristet Bonobo in Gnome schon seit einiger Zeit ein Schattendasein. D-Bus sollte deshalb einfacher werden und beginnt entsprechend klein: Die grundlegende Bibliothek Libdbus stellt nur Funktionen für die Kommunikation zweier Applikationen zur Verfügung. Anwendungsentwickler machen von ihr normalerweise keinen Gebrauch. Für sie gibt es die auf dem Glib-API basierende Libdbus-Glib, die ein objektorientiertes C-API bereitstellt. Auf dieser Ebene erweitern sich die Fähigkeiten von D-Bus hin zu einem Bus-System – wie es der Name bereits andeutet. Der Serverprozess »dbus-daemon« läuft im Hintergrund und wartet auf Verbindungsanfragen von Anwendungen, die sich für bestimmte Ereignistypen registrieren, zum Beispiel für das Ein- und Ausstecken von Hardware. Tritt ein solches Ereignis ein, schickt der D-Bus-Daemon eine entsprechende Nachricht über den Bus und die Anwendungen können darauf reagieren. Systemweit oder pro Session Prinzipiell gibt es auf Systemen, die D-Bus verwenden, zwei von je einem Serverprozess realisierte Busse: den System-Bus und den Session-Bus. Der System-Bus startet beim Booten und ist auch dann aktiv, wenn kein Benutzer eingeloggt ist. Erst beim grafischen Login einer Desktop-Session startet auch ein Serverprozess für den Session-Bus. Das Binary »dbus-daemon« kennt für die beschriebenen Modi die Kommandozeilenparameter »–system« respektive »–session«. Zum Starten des Daemon enthält das D-Bus-Paket das Programm »dbus-launch«, das unter anderem die nötigen Umgebungsvariablen setzt. Die meisten Distributionen starten damit den D-Bus-Daemon im Session-Modus zusammen mit der X-Session. Abbildung 4 zeigt die Stellung beider Busse in der Kommunikation zwischen den Betriebssystem-Komponenten. Der Session-Bus ermöglicht es Anwendungen, die zu einer Desktop-Sitzung gehören, miteinander zu sprechen. Das können durchaus auch Dienste sein, die zum Beispiel die Desktop-Umgebung zur Verfügung stellt. Der System-Bus ist in erster Linie dafür gedacht, dass Desktop-Programme mit den darunter liegenden Schichten kommunizieren. So kann eine Anwendung sich über den System-Bus für eine Hardwareklasse registrieren. Ereignisbehandlung Events, die der Hardware Abstraction Layer aufgrund von Hardware-Interrupts der Bus-Controller auslöst, können Programme im Userspace auf vielfältige Weise auswerten. Unter Gnome kümmert sich beispielsweise der Gnome Volume Manager darum, unter KDE der Kioslave Media. Für die Desktop-unabhängige Reaktion lässt sich die Software Ivman einsetzen, die beispielsweise auch unter XFCE funktioniert (siehe Artikel im Schwerpunkt). Abbildung 4: Nach diesem Schema funktioniert das Zusammenspiel der Komponenten für die dynamische Geräteverwaltung. Auf der Anwendungsebene kümmern sich verschiedene Programme um die Nachrichten.

Fehlersuche

Bei der Fehlersuche hilft der Udev-Daemon durch seinen einstellbaren Logging-Level, der bei der Standardeinstellung »err« allerdings nur Fehler ausgibt. Mit der Vorgabe »info« wird der Udevd etwas mitteilsamer, die Vorgabe »debug« macht ihn regelrecht geschwätzig. Diese Werte kann man entweder in die Konfigurationsdatei eintragen oder zur Laufzeit über das Utility »udevcontrol« einstellen. Den Loglevel setzt zum Beispiel der Eintrag »udevcontrol log_priority=debug«. Über die Anweisung »reload_rules« bewegt Udevcontrol den Udev-Daemon zum erneuten Laden aller Regeln.

Vielschichtig

Udev ist ein komplexes System, das aus mehreren zusammenwirkenden Schichten besteht: einem Daemon sowie eventuell Hotplug-Skripten und Hilfsprogrammen für die Event-Verarbeitung. Es ermöglicht auf aktuellen Linux-Systemen dynamisches Gerätehandling, das den Anforderungen moderner Hardware gerecht wird: So berücksichtigt es unter anderem auch gegenseitige Abhängigkeiten, etwa von Partitionen und Festplatten, und verwaltet die heute verbreiteten Hotplugging-Geräte, zum Beispiel am USB-Bus.

Fazit

Obwohl die meisten Distributionen Udev in ihren aktuellen Versionen bereits einsetzen, steckt das Paket noch in der Entwicklungsphase. Es kommen immer noch ganze Programme neu hinzu, alte fallen weg, ein Beispiel dafür ist das einstige Binary »udev« selbst. Die Unterschiede zwischen verschiedenen Distributionen, aber selbst zwischen mehreren Versionen ein und derselben Distribution sind zum Teil erheblich, wie auch die Tabelle 1 belegt.

Die benutzten Verfahren überlappen sich teilweise in ihrer Funktion, für die Geräteverwaltung und Ereignisbehandlung gibt es im Userspace diverse Programm-alternativen, die auch parallel installiert sein können, was allerdings nicht gerade zur Übersichtlichkeit beiträgt. Die meisten Dokumentationen im Internet sind leider veraltet. Im Zweifel kann man sich nur auf die eigene Erkundung seines Systems verlassen, die jedoch etwas Zeit erfordert.

Wer nur das vom Distributor ausgelieferte Udev verwenden will, hat damit in aller Regel keine Probleme. Hier sind die Komponenten aufeinander abgestimmt und meist sinnvoll vorkonfiguriert. Wer aber selber in die Konfiguration eingreifen möchte, kommt um das Lesen und Verstehen der mitgelieferten Skripte schwerlich herum.

Einige Hinweise zum Schreiben eigener Udev-Regeln gibt [3], aber aus den erwähnten Gründen ist auch diese Seite nicht in jedem Aspekt auf dem allerneuesten Stand. Die vergleichsweise frischesten Informationen finden sich gegenwärtig im Weblog des Udev-Maintainers Kay Sievers [4]. Daneben liefern aber auch die ganz brauchbaren Manpages des Programms selbst eine recht gute Hilfestellung für eigene Konfigurationsversuche.