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.

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"
…

Abbildung 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”).

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.

cat /sys/block/hda/dev
3:0

BUS="usb", KERNEL="lp[0-9]*", NAME="usb/%k"

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

BUS="usb", SYSFS{serial}="HXOLL0012202323480", NAME="lp-epson"

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.