Mit heißer Nadel
Hotplugging mit Udev, HAL und D-Bus
Eigene Usermaps
Es gibt noch einen weiteren Weg, Hardware an den eigenen Bedarf anzupassen: die beschriebenen Usermaps im Verzeichnis /etc/hotplug. In einer solchen Datei stehen ein oder mehrere IDs, die eine Hardwarekomponente identifizieren. Passt ein solcher Eintrag auf ein neu eingestecktes Gerät, führt das Subsystem das vorgegebene Programm aus. Dabei kann es sich auch um ein Skript handeln. Damit lässt sich zum Beispiel ein WLAN-USB-Adapter konfigurieren, den die Distribution nicht selbst als solchen erkennt.
Das Hotplug-System erkennt im Test zwar den Adapter mit Prism2-Chipsatz, führt aber nicht das Skript zum Starten der WLAN-Funktionen aus. Der Befehl lsusb zeigt die USB-IDs des Geräts: Die Vendor-ID lautet im Beispiel 0846, die Geräte-ID 4110.
Diese hexadezimalen Werte trägt man in folgender Form in eine neue Datei /etc/hotplug/usb/prism2.usermap ein:
prism2 0x0003 0x0846 0x4110↩ 0x0000 0x0000 0x00 0x00 0x00 ↩ 0x00 0x00 0x00 0x0
Die meisten solcher Maps sehen ähnlich aus und verwemden nur die ersten vier Werte. Der erste legt fest, welches Programm das Hotplug-System ausführt, wenn die in der Zeile folgenden Werte zutreffen. Beim ersten numerischen Wert handelt es sich um ein Bit-Feld, das die nötige Anzahl zutreffender Werte bestimmt. Soll Hotplug die ersten beiden Werte überprüfen, steht hier 0x0003 – das erste Bit steht für den Wert 1, das zweite für 2, macht zusammen 3. Die restlichen Spalten der Datei beachtet Hotplug damit nicht, deshalb steht in ihnen nur eine 0x00.
Das auszuführende Skript prism2 legen wir im selben Verzeichnis ab und geben ihr mit chmod +x Ausführungsrechte. In unserem Beispiel führt es das im Prism2-Paket enthaltene Startskript rc.wlan aus, konfiguriert die Netzwerkschnittstelle wlan0 und holt schließlich eine IP-Adresse vom DHCP-Server:
#!/bin/sh /etc/rc.wlan start /sbin/ifconfig wlan0 up /sbin/dhclient wlan0
Nun funktioniert der USB-WLAN-Adapter direkt nach dem Einstecken. Entsprechende Versuche, eine DV-Videolamera ähnlich zu konfigurieren, scheiterten am schlechten Zustand des Firewire-Subsystems: Die IEEE1394-Treiber aktueller Kernel zeigen nicht die nötigen Informationen im SysFS an. Hier bleibt keine Wahl, als weiterhin mit mknod eigene Gerätedateien anlegen.
Von der Hardware zur Applikation
Eine weitere Ebene des Hotplugging-Systems vermittelt zwischen Hardware und Anwendungen: der Hardware Abstraction Layer (HAL, [4]). Er hält detaillierte Informationen über die Hardware vor, die in so genannten Geräteinformationsdateien (Device Information Files, .fdi) gespeichert sind.
Über die HAL-Schicht können Sie weitere Anpassungen für Ihr spezielles Gerät vornehmen. Zum Beispiel hat ein Benutzer auf diese Weise das Problem gelöst, dass sein iPod nicht fehlerfrei vom System abgemeldet wurde [5].
Die FDI-Dateien beschreiben im XML-Format das Gerät näher. Der Befehl lshal zeigt diese Informationen ausführlich an. Der hal-device-manager bereitet dieselben Daten mit grafischer Oberfläche übersichtlich auf (Abbildung 2). Suse-Benutzer müssen auf HAL-Komponenten verzichten, denn ihre Distribution verwaltet Details zur Hardware anders (siehe Kasten "Hotplug unter Suse Linux").
Abbildung 2: Der hal-device-manager zeigt Details zum Prism2-WLAN-Adapter.
In Zukunft sollen Anwendungen über den D-Bus [6] Hardwaredetails erfragen können. Dabei handelt es sich um ein in Software implementiertes Kommunikationssystem, in das sich Anwendungen einklinken und für bestimmte Events registrieren können. So erhält ein Videoschnittprogramm die Nachricht, dass eine neue Kamera am PC steckt. Das Programm gnome-volume-properties aktueller Gnome-Versionen benutzt D-Bus und HAL dafür, die Anwendungen festzulegen, die bei bestimmten Hotplug-Events ausgeführt werden (Abbildung 3).
Abbildung 3: In Gnome 2.8 legt gnome-volume-properties Anwendungen für einige Hotplugging-Fälle fest.
D-Bus soll zum Beispiel unter Gnome eine wesentliche Rolle in der Kommunikation zwischen Anwendungen spielen. Zur Zeit machen noch wenige Anwendungen davon Gebrauch.
Hotplug unter Suse Linux
Suse Linux verfolgt bei Hotplug ein teilweise anderes Konzept und verzichtet in den aktuellen Versionen auf die HAL-Architektur. Es unterscheidet zwischen (noch) nicht bekannten und bereits konfigurierten Devices und benutzt zur Unterstützung von Hotplug die Programme hwup, hwdown, hwstatus und hwscanqueue. Für bereits konfigurierte Geräte legt Suse in /etc/sysconfig/hardware die entsprechende Konfigurationsdatei ab. Registriert der Kernel ein Hotplug-Event, lädt /sbin/hotplug das passende Kernelmodul.
Anschließend überprüft hwup, ob für das Gerät unter /etc/sysconfig/hardware eine Konfigurationsdatei existiert und lädt die darin angegebenen Module. Findet hwup keine Konfigurationsdatei, versucht es die benötigten Module über die *.usermap-Dateien in /etc/hotplug/ ausfindig zu machen, wie es auch die anderen Distributionen tun. In Zukunft will Suse für jede Hardwarekomponente eine Datei in /etc/sysconfig/hardware anlegen, um ganz auf die Usermap-Dateien verzichten zu können. Ein Vergleich der letzten beiden Suse-Versionen weist bereits in diese Richtung: Während 9.1 Konfigurationsdateien lediglich für Netzwerkgeräte anlegt, finden sie sich unter 9.2 auch für Festplatten, CD/DVD-Laufwerke und zahlreiche USB-Geräte.
Nachdem hwup seine Arbeit beendet hat, startet der entsprechende Hotplug-Agent. Bei einem USB-Event tritt der USB-Agent in Aktion, bei einem Netzwerk-Event der Netzwerk-Agent usw. Findet das Hotplug-System keinen passenden Agenten, startet es einen allgemeinen Agenten, um zum Beispiel per Udev die nötige Gerätedatei anzulegen. Der entsprechende Agent überprüft seit Suse Linux 9.2 auch, ob unter /etc/sysconfig eine zum Dienst gehörende Konfigurationsdatei existiert und startet dann den entsprechenden Dienst.
Um die Ursache von Problemen zu finden, bietet Suse Linux eine einfache Möglichkeit, Hotplug etwas gesprächiger zu machen. Dazu setzen Sie in der Datei /etc/syconfig/hotplug die Variable HOTPLUG_DEBUG auf yes oder sogar auf max. Mit letzterer Einstellung protokolliert das System jeden einzelnen Schritt ausführlich in /var/log/messages.
Desktop-Icons unter Suse Linux
Seit Version 9.1 legt Suse Linux für Laufwerke keine Icons mehr auf dem Desktop an. Benutzer sollen stattdessen über das Arbeitsplatz-Icon (wie unter Windows) oder die URL drives:/ auf ihre Geräte zugreifen. Das ist bei USB-Memorysticks nicht immer die optimale Lösung. Suse öffnet zwar in der Grundeinstellung beim Anschließen eines USB-Sticks ein Konqueror-Fenster mit dem Inhalt der entsprechenden Partition. Haben Sie dieses Feature abgeschaltet, oder das Fenster geschlossen, müssen Sie aber wieder den Weg über den Arbeitsplatz gehen.
Für die URL drives:/ benutzt Suse Linux auch eigene Icons. Sie finden diese unter /usr/share/hotplug/DesktopTemplates/. KDE trägt dann die entsprechenden Namen in die Datei ~/.kde/share/config/kio_drivesrc ein. Diese Datei können Sie editieren, um Ihren Geräten eindeutige Namen zuzuordnen. Besitzen Sie zum Beispiel zwei Memorysticks, editieren Sie einfach in dieser Datei die entsprechenden Einträge unter [Used Names].
Um unter Suse die Geräte-Icons des KDE-Desktops zu aktivieren, müssen Sie zunächst die Pakete kdebase3-extra und kdemultimedia3-extra nachinstallieren. Vorsicht bei Suse 9.2: Die Pakete befinden sich nur auf der DVD! Danach klicken Sie mit der rechten Maustaste auf den KDE-Desktop und wählen Arbeitsfläche einrichten... aus dem Kontextmenü. Unter dem Punkt Verhalten wechseln Sie auf den Reiter Geräte-Symbole und kreuzen dann die Option Geräte-Symbole anzeigen an. Nun können Sie anhand der Liste einstellen, von welchen Geräten Sie Symbole auf der Arbeitsfläche haben möchten. Nach der Installation von kdebase3-extra und kdemultimedia3-extra funktioniert die URL devices:/ in Konqueror.
Gerätedateien mit UDev
Unter Linux greifen Anwendungen über so genannte Gerätedateien (Device Files) auf Hardware zu. Diese speziellen Dateien im Verzeichnis /dev sind durch Typ, Major- und Minor-Nummer definiert, die sie mit dem Kernel verbinden.
In der Vergangenheit enthielt dieses Verzeichnis Dateien für alle möglichen Geräte, also für IDE- und SCSI-Festplatten, USB, IEEE-1394 und virtuelle Geräte. Damit befanden sich im Verzeichnis /dev meist einige tausend Einträge.
Dieses System hat ein paar Nachteile: Es liefert keinen Anhaltspunkt dafür, welche Geräte wirklich vorhanden sind oder korrekt von Treibern erkannt wurden. Außerdem können sich die Gerätedateien von Fall zu Fall ändern, das heißt welches SCSI-Gerät über /dev/sg2 angesprochen wird, hängt von der zufälligen Reihenfolge ab, in der es dem System hinzugefügt wurde.
Neue Welt
Udev [1] ist designierte "Nachfolger" der fixen Gerätedateien und kommt dementsprechend auf den meisten aktuellen Distributionen zum Einsatz. Es verwendet den Hotplug-Mechanismus um nach Bedarf Gerätedateien anzulegen. Der Kernel ruft bei Veränderungen an Geräten das in /proc/sys/kernel/hotplug eingetragene Programm auf, standardmäßig /sbin/hotplug. Dieses kann dann je nach Art des Gerätes Module laden, Zugriffsrechte ändern, Netzwerkgeräte konfigurieren oder eben, im Fall von Udev, Device Nodes verwalten.
Udev benötigt für das Anlegen der Dateien einige Informationen: den Typ des Geräts (char oder block) und die Major- und Minor-Nummer. Diese erhält Udev ab 2.6 Kernel über das Sys-Dateisystem (SysFS), das normalerweise unter /sys zu finden ist.
Blockgeräte finden sich in /sys/block und Zeichengeräte (Character Devices) in /sys/class. Dabei stehen Major- und Minor-Nummern jeweils in einer Datei namens dev. Zum Beispiel zeigt folgender Befehl die Nummern der ersten IDE-Festplatte hda:
cat /sys/block/hda/dev 3:0
Udev kann alle SysFS-Informationen wie Geräteklasse, Name, Nummern usw. heranziehen, um die passenden Devices zu erzeugen. Für stabile Namen kann es sogar beliebig komplexe Programme ausführen, um beispielsweise anhand der Seriennummer des Druckers zu entscheiden, ob der soeben eingeschaltete Drucker /dev/usb/lp0 oder doch /dev/usb/lp1 ist. Es ist sogar möglich, beliebige Namen zu verwenden und die Nodes /dev/lp-epson und /dev/lp-kyocera zu nennen.
Udev einstellen
Zur Konfiguration bietet Udev zwei Möglichkeiten: Dateien in /etc/udev/rules.d/ legen die Namen der Gerätedateien fest, andere in /etc/udev/permissions.d/ die Rechte. Die mitgelieferten Regeln erzeugen Gerätedateien mit den unter Linux bekannten Namen.
Zu Beginn jeder Regel stehen eine oder mehrere Bedingungen, die erfüllt sein müssen, damit Udev eine Gerätedatei anlegt. Danach folgt der gewünschte Name. Ein Eintrag für USB-Drucker lautet zum Beispiel:
BUS="usb", KERNEL="lp[0-9]*", NAME="usb/%k"
Wenn das Gerät am Bus usb hängt und der interne Kernel-Name lp mit beliebiger Nummer lautet, legt Udev eine Datei mit dem Kernel-Namen (dafür steht das %k) im Verzeichnis /dev/usb an.
Neben solch statischen Regeln sind auch externe Programmaufrufe möglich. Für IDE-CD-ROMs enthält die Manpage ein Beispiel, das überprüft, ob ein Verzeichnis /proc existiert, welches das Gerät als CD-ROM identifiziert:
KERNEL="hd[a-z]", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom", NAME="%k", SYMLINK="cdrom%e"
Hier ruft Udev für alle Geräte, deren Name mit "hd" beginnt, /bin/cat mit der entsprechenden /proc-Datei auf. Falls diese als Medium cdrom ausgibt, behält Udev den Namen zwar bei, legt aber zusätzlich einen symbolischen Link cdrom an. Das %e lässt Udev die nächste freie Zahl wählen, falls eine Datei mit diesem Namen schon existiert.
Interessant ist auch der Einsatz der Geräte-Seriennummer, um aussagekräftige Namen zu erhalten:
BUS="usb", SYSFS{serial}="HXOLL0012202323480", NAME="lp-epson"
Mit dieser Regel erzeugt Udev eine Gerätedatei /dev/lp-epson, wenn es ein Gerät findet, dessen Datei serial im SysFS-Baum die obige Nummer enthält.
Udev und Rechte
Die Regeln für die Zugriffsrechte bestehen einfach aus einer Zeile mit durch Doppelpunkte getrennten Werten für Name, Besitzer, Gruppe und Rechte.
usb/lp*:root:lp:0660
Alle Gerätedateien mit Namen usb/lp* gehören dem Benutzer root und der Gruppe lp. Die Zugriffsrechte selbst sind im Oktalformat angegeben.
Das neue Hotplugging-Modell ist so erfolgreich, dass es sogar beim Systemstart zum Einsatz kommt. Es ruft udev für alle bereits erkannten Geräte in /sys/class und /sys/block mit den passenden Variablen auf.
Einem Freund empfehlen
