Mit heißer Nadel

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