Neues Netbook? Ein Preisvergleich lohnt sich.

Bei uns finden sie Notebooks, PDAs und Drucker mit Testberichten und Tipps.

Diamant Buchhaltungssoftware – transparent und detailliert auch für die Konzernbuchhaltung.

Günstige Shareware Programme als direkte Downloads im Software Portal.

Bis zu 70% sparen durch Preisvergleich.

Erschienen in LinuxUser 03/2005 » Ausgabe bestellen

Hotplugging mit Udev, HAL und D-Bus

Mit heißer Nadel

Hardware, die einfach funktioniert, wenn man sie am PC ansteckt -- das ist der berechtigte Wunsch jedes Anwenders. Aktuelle Linux-Distributionen tun einiges dafür. Wir erklären, wie die einzelnen Komponenten des zuständigen Hotplug-Systems zusammenspielen.

von Oliver Frommel, Marcel Hilzinger und René Rebe

Kann das denn wirklich so schwer sein? Sie wollten doch nur, dass Linux das richtige Programm startet, als Sie die neue Digitalkamera einsteckten. Doch das Betriebssystem begegnet Ihnen mit eisigem Schweigen.

Diese Situation ist nur allzu bekannt, auch wenn sich mittlerweile einiges verbessert hat. Unser Artikel erklärt, was ein modernes Linux mit frisch eingesteckten Geräten macht und warum noch immer nicht alles nach Wunsch funktioniert.

Prinzipiell soll Linux natürlich mit jeder Art von Hardware richtig umgehen. Besondere Bedeutung gewinnt mit der Verbreitung von USB und Firewire die Fähigkeit, während des Betriebs ein- und ausgesteckte Geräte richtig zu verwalten, das so genannte Hotplugging [1].

Agenten im Einsatz

Eine Schlüsselrolle beim Hotplugging spielen die Skripts in /etc/hotplug/, die so genannten Agenten. Sie treten in Aktion, wenn der Kernel dem Hotplug-System ein Ereignis (Event) signalisiert, in der Regel das Anschließen oder Ausstecken externer Hardware.

Es existieren zwei Typen von Ereignissen: Während ein Device Event für die grundlegende Initialisierung des Gerätes sorgt, richtet Hotplug bei einem Interface Event das Gerät quasi benutzerfertig ein, bereitet also die Schnittstelle (Interface) für Anwendungen vor.

Dazu legt Hotplug mit Hilfe von Udev die entsprechende Gerätedatei an und ruft anschließend den zuständigen Agenten auf. Mehr Details zu UDev liefert der entsprechende Kasten.

Für jeden Agenten sind verschiedene Aktionen festgelegt, die ihm das in /proc/sys/kernel/hotplug definierte Hotplug-Programm als Parameter übergibt: add respektive register für das Anschließen der Komponente und remove oder unregister für das Entfernen. Welche Schritte die einzelnen Agenten genau ausführen, hängt von der benutzten Distribution und der jeweiligen Hardwarekomponente ab.

Da ein großer Teil der hotplug-fähigen Hardware über USB an das System angeschlossen wird, bewerkstelligt die meisten Aufgaben der USB-Agent. Er überprüft zunächst, ob er für das neue Gerät einen Treiber findet (zum Beispiel isdn) und lädt dann das entsprechende Modul über modprobe. Findet er ein zum Treiber gleichnamiges Skript im Verzeichnis /etc/hotplug/usb/, führt er es aus.

Damit hat er seine Aufgabe eigentlich schon beendet. Das Laden der entsprechenden Module löst aber meistens weitere Hotplug-Events aus, die wieder andere Agenten starten.

Bei vielen Hardware-Elementen arbeiten deshalb mehrere Hotplug-Agenten zusammen. So startet beim Anschließen einer externen Festplatte erst der USB-Agent, dann der SCSI-Agent, um mit Hilfe des Moduls usb-storage die einzelnen Partitionen als SCSI-Geräte einzubinden. Bei einem Bluetooth-Dongle startet zuerst der USB-Agent, dann der bluetooth.agent.

Eine weitere Aufgabe der Hotplug-Agenten ist das Laden der Firmware, sofern es das entsprechende Gerät verlangt. Die Datei /etc/hotplug/blacklist führt Module auf, die keiner der Agenten laden darf. auf. Hier finden sich Module, die das System über andere Dienste startet, oder die das Powermanagement behindern.

Gerätedateien nach Bedarf

Damit Linux die Hardware benutzen kann, braucht es in den allermeisten Fällen Gerätedateien. Auf modernen Distributionen legt das Udev-Subsystem diese an, wenn ein neues Gerät im Kernel auftaucht.

Wer beispielsweise seinem MP3-Stick eine andere Gerätedatei als sda1 zuweisen will, kann dafür eine eigene Udev-Regel schreiben. Bei der Vielzahl an Skripts im Hotplug-System gibt es auch andere Wege, wir beschränken uns erst einmal auf diese Lösung.

Die Udev-Regeln liegen im Verzeichnis in /etc/udev/rules.d. Dort befindet sich eine Datei, die übliche Geräte beschreibt, unter Ubuntu udev.rules, bei Fedora 50-udev.rules. Udev liest die Dateien in lexikalischer Reihenfolge. Wer eigene Udev-Regeln vor der systemweiten gelesen wissen möchte, muss also einen passenden Dateinamen verwenden, zum Beispiel 10-local.rules. Für einen Noname-MP3-Stick verwendeten wir darin folgenden Eintrag:

BUS="usb", SYSFS{idProduct}=\
"1000", SYSFS{idVendor}="10d6",\
 NAME="mp3disk"

Nun zeigt der Gnome-Desktop nicht mehr die Gerätebezeichnung sda1, sondern das etwas aussagekräftigere mp3disk an (Abbildung ((1))). Beim Finden der verwendenten USB-IDs hilft das Programm lsusb, das die angeschlossenen USB-Geräte auflistet. Existiert schon eine Gerätedatei, zeigt udevinfo -q path -n /dev/Gerätedatei den Pfad im SysFS (siehe Kasten Udev) -- allerdings ohne den Mount-Punkt /sys. Dieser Pfad dient wieder als Parameter (-p) für denselben Befehl, um SysFS-Infos anzuzeigen:

udevinfo -a -p /block/hda/hda1
...
    SYSFS{idVendor}="10d6"
...

((1)) Mit einer angepassten Udev-Konfigurationsdatei erhält das Icon auf dem Gnome-Desktop eine passende Beschriftung.

Auch so finden sie also gerätespezifische Werte, die Sie für spezielle Konfigurationen verwenden können. Eine ausführliche, englischsprachige Beschreibung, wie man Udev-Dateien erstellt, findet sich unter [2]. Die Fedora-Site bietet einen knappen Überblick des Udev-Systems [3].

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").

((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))).

((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.

Kasten 1: 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.

Alles wird gut -- irgendwann

Trotz großer Fortschritte bei der Geräteerkennung ist noch nicht alles im Lot. Die Agenten des Hotplug-Systems benötigen detaillierte Hardware-Informationen, die bei einem mehrere Monate alten System notwendigerweise veraltet sind. Abhilfe könnte eine Datenbank für Hardware-Komponenten schaffen, die online zur Verfügung steht. Dazu könnten auch Endbenutzer könnten die mühselig erarbeiteten Daten im FDI-Format wieder beisteuern.

Das HAL-Projekt geht in diese Richtung, denn es versorgt das Hotplugging-System mit Informationen, die nicht in den Kernel gehören. Dass bereits mehrere Distributionen es verwenden, ist ein gutes Zeichen. Hoffentlich schließt sich auch Suse diesem Trend an, denn je einheitlicher die Hardwareverwaltung unter Linux, desto besser. (ofr)

Infos

[1] Linux-Hotplug: http://linux-hotplug.sourceforge.net
[2] Eigene Udev-Regeln schreiben: http://www.reactivated.net/udevrules.php
[3] Fedora Udev-Dokumentation: http://fedora.redhat.com/docs/udev
[4] HAL: http://www.freedesktop.org/Software/hal
[5] iPod mit Udev: http://www.kgarner.com/blog/archives/2005/01/11/fc3-hal-ipod/
[6] D-Bus: http://www.freedesktop.org/Software/dbus

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen.