Aufmacher

Sauber verzahnt

Dynamische Geräteverwaltung mit Udev & Co.

01.09.2008
Einstecken, loslegen: Linux reagiert vollautomatisch auf neue Hardware, sogar im laufenden Betrieb. Doch was steckt dahinter?

Linux und Hardware – das ist bekanntlich ein Thema für sich. Wer schon länger mit Linux arbeitet, kennt die Probleme bei der Installation neuer Hardware zur Genüge. War es früher nötig, fast jede neue Hardware manuell einzubinden, beherrscht das freie Betriebssystem inzwischen nicht nur das automatische Erkennen von Hardware während des Systemstarts, sondern reagiert auch auf im laufenden Betrieb auf angeschlossene Hardware – egal ob USB-Stick, Digicam oder Bluetooth-Handy. Das Subsystem Udev macht den Zugriff auf jedes neue Gerät einfach; der Hardware Abstraction Layer (HAL) und der D-Bus helfen dabei, die richtige Desktop-Applikation zu starten. Doch wie arbeiten diese Komponenten zusammen?

Ein direkter Draht

Mussten Sie früher eine eingelegte CD oder DVD noch manuell mounten, so übernimmt das zum Beispiel unter Gnome der gnome-volume-manager für Sie vollautomatisch. Er legt dynamisch ein Desktop-Symbol an, über das Sie auf die CD oder DVD zugreifen. Auch andere externe Massenspeicher, wie beispielsweise einen USB-Stick, bindet die Software automatisch ins System ein. Dazu erstellt Gnome-volume-manager im Verzeichnis /media ein entsprechendes Verzeichnis, unter dem er das Gerät einhängt. Das Verzeichnis erhält dabei den Namen, mit dem sich das Gerät am System angemeldet hat.

Je nach Konfiguration startet der Manager zusätzlich die passende Applikation. Bei Massenspeichern wie CD/DVDs, USB-Sticks oder USB-Festplatten öffnet sich auf Wunsch der Dateibrowser. Er zeigt direkt den Inhalt des unter dem Mountpoint dynamisch eingebundenen Geräts an (Abbildung 1). Schließen Sie eine Digicam an, ruft Gnome-volume-manager ein Bildbetrachtungsprogramm auf oder startet dessen Import-Routine.

Abbildung 1: Der Gnome-volume-manager startet automatisch die gewünschte Aktion – in diesem Fall den Dateibrowser zum Anzeigen des Inhalts eines USB-Sticks mit der Bezeichnung DISK_IMG.

Der Gnome-volume-manager bietet umfangreiche Konfigurationsmöglichkeiten. Hierzu dient das Programm gnome-volume-properties, das Sie zum Beispiel über ein Terminalfenster in Gnome aufrufen (Abbildung 2).

Abbildung 2: Das Programm Gnome-Volume-Properties legt das Verhalten des Gnome-Volume-Managers fest.

Hierbei legen Sie das Verhalten für bestimmte Geräteklassen wie Digitalkameras, Massenspeicher, Drucker und Scanner separat fest. So erkennt das System zum Beispiel auch automatisch neue Drucker und bindet diese in das System ein – einfacher geht's nicht.

Obwohl Gnome in dieser Hinsicht den Vorreiter gespielt hat, bietet natürlich auch KDE ein entsprechendes Framework. Experimentierte KDE früher mit eigenen Lösungsansätzen wie Corba oder DCOP, so stellten die Entwickler vor einiger Zeit auf auf Udev/HAL/D-Bus um. Hinsichtlich des dynamischen Gerätemanagements basieren damit beide Desktop-Umgebungen auf dem selben Unterbau.

KDE setzt seit der Version 4 auf das Programmpaket Solid, um einen vergleichbaren Komfort zu bieten, wie man ihn von Gnome schon länger kennt. Dabei versteht sich Solid als Framework und arbeitet – ähnlich wie Gnome-volume-manager – mit den passenden Applikationen zusammen. Bei der dynamischen Verwalten von Geräten spielen also eine ganze Reihe von Komponenten eine Rolle.

Hinter den Kulissen

Um zu verstehen, wie die Komponenten des Trios zusammenarbeiten, lohnt es sich, einen Blick hinter die Kulissen zu werfen. Da läuft zum Beispiel das Programm Udev als Daemon udevd im Hintergrund. Grundsätzlich dient Udev dazu, dynamisch Gerätedateien unter /dev zu erzeugen, sobald es neue Geräte erkennt. Dieser Vorgang findet nicht nur beim Systemstart, sondern auch während des laufenden Betriebs statt – Stichwort: Hotplug. Dabei legt das Programm zum Beispiel Massenspeicher wie Festplatten oder USB-Sticks unter /dev/disk in verschiedenen Unterverzeichnissen als symbolische Links an, die auf die eigentliche Gerätedatei unter /dev verweisen.

Das Udev-System sorgt dabei dafür, dass nur diejenigen Gerätedateien bereitstehen, hinter denen sich die tatsächlich vorhandene Geräte verbergen. Angenommen, Sie möchten die Bilder einer Digicam auf den Computer übertragen oder über ein Fotobetrachtungsprogramm wie F-Spot ansehen. Als erstes schließen Sie dazu die Kamera über ein USB-Kabel an den Computer an.

Der Kernel überwacht den USB-Bus und erkennt das neu angeschlossene Gerät. Über ein so genanntes Uevent meldet er den Fund an den Udev-Daemon. Das Udev-System verarbeitet die Information, indem es die Daten des entsprechenden Gerätes aus der Kernel-Gerätedatenbank Sysfs ausliest. Wie Udev mit dem neuen Gerät verfährt, legen die Udev-Regeln fest. Die befinden sich unter /etc/udev/rules.d/ und teilen sich in einzelne Dateien auf, die jeweils die Aktionen für verschiedene Ereignisse festlegen.

Wie Listing 1 zeigt, beginnen die Namen der Regeldateien mit Ziffern. Das dient dazu, die Reihenfolge des Abarbeitens festzulegen, da unter Umständen bestimmte Abhängigkeiten bestehen. Möchten Sie Näheres über das Erstellen von Regeln für Udev erfahren, finden Sie im Artikel-Archiv von LinuxUser [1] die passenden Informationen.

# ls /etc/udev/rules.d/
05-udev-early.rules          64-md-raid.rules
40-alsa.rules                70-kpartx.rules
40-bluetooth.rules           70-persistent-cd.rules
50-udev-default.rules        70-persistent-net.rules
55-hpmud.rules               75-cd-aliases-generator.rules
55-libsane.rules             75-persistent-net-generator.rules
56-idedma.rules              77-network.rules
60-cdrom_id.rules            79-yast2-drivers.rules
60-persistent-input.rules    80-drivers.rules
60-persistent-storage.rules  90-hal.rules
64-device-mapper.rules       95-udev-late.rules

Wie Udev arbeitet, beobachten Sie bei Bedarf im laufenden Betrieb. Hierzu dient das Programm Udevmonitor. Es zeigt Ihnen die Uevents des Kernels beim Anschluss eines Geräts (zum Beispiel eines USB-Sticks) sowie die Reaktion von Udev (Listing 2).

# udevmonitor
udevmonitor will print the received events for:
UDEV the event which udev sends out after rule processing
UEVENT the kernel uevent
UDEV  [1212504262.814732] add      /devices/pci0000:00/0000:00:1d.7/usb3/3-1 (usb)
UDEV  [1212504262.814934] add      /devices/pci0000:00/0000:00:1d.7/usb3/3-1/usb_endpoint/usbdev3.7_ep00 (usb_endpoint)
UDEV  [1212504262.815017] add      /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0 (usb)
UDEV  [1212504262.815086] add      /class/scsi_host/host5 (scsi_host)
UDEV  [1212504262.815146] add      /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/usb_endpoint/usbdev3.7_ep01 (usb_endpoint)
UDEV  [1212504262.815193] add      /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/usb_endpoint/usbdev3.7_ep81 (usb_endpoint)
UEVENT[1212504263.666057] add      /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host5/target5:0:0/5:0:0:0 (scsi)
UEVENT[1212504263.666112] add      /class/scsi_disk/5:0:0:0 (scsi_disk)
UEVENT[1212504263.673463] add      /block/sdb (block)
UEVENT[1212504263.673511] add      /block/sdb/sdb1 (block)
UEVENT[1212504263.673538] add      /class/scsi_device/5:0:0:0 (scsi_device)
UEVENT[1212504263.673565] add      /class/scsi_generic/sg2 (scsi_generic)
UDEV  [1212504263.716085] add      /devices/pci0000:00/0000:00:1d.7/usb3/3-1/3-1:1.0/host5/target5:0:0/5:0:0:0 (scsi)
UDEV  [1212504263.733094] add      /class/scsi_disk/5:0:0:0 (scsi_disk)
UDEV  [1212504263.793736] add      /class/scsi_device/5:0:0:0 (scsi_device)
UDEV  [1212504263.823559] add      /class/scsi_generic/sg2 (scsi_generic)
UDEV  [1212504263.831015] add      /block/sdb (block)
UDEV  [1212504263.900340] add      /block/sdb/sdb1 (block)

Alle mit UEVENT beginnenden Zeilen entsprechen den Kernelmeldungen, während die mit UDEV beginnenden Zeilen die Udev-Aktionen kennzeichnen (Abbildung 3). Das neue Gerät steht unter der Gerätedatei /dev/sdb1 bereit, wie die letzte Zeile von Listing 2 (indirekt) erkennen lässt. Ein Blick in /dev/disk/by-label zeigt einen Link mit dem Namen, mit dem sich der USB-Stick am System anmeldet. Der entsprechende symbolische Link lautet für den Beispiel-Stick DISK_IMG. Er zeigt folgerichtig auf /dev/sdb1, was zur Ausgabe von Udevmonitor passt.

Abbildung 3: Das Programm Udev organisiert zu Laufzeit dynamisch das Anlegen und Löschen von Gerätedateien.

In diesem Fall hat das System den Namen übernommen. Viele Geräte melden sich mit ihrer Typenbezeichnung oder zumindest mit dem Namen des Herstellers an, leider aber nicht alle. In vorliegenden Beispiel sagt DISK_IMG also nicht viel aus.

Im Falle von USB-Geräten stellen Sie die Bezeichnung der angeschlossenen Geräte bei Bedarf über den Befehl lsusb fest, wie Listing 3 zeigt. In diesem Fall handelt es sich um eine Hewlett-Packard-Tastatur und eine Digicam, die sich vorbildlich mit ihrer vollen Typenbezeichnung anmeldet.

# lsusb
Bus 001 Device 005: ID 03f0:0024 Hewlett-Packard
Bus 001 Device 001: ID 0000:0000
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 002 Device 002: ID 04a9:3073 Canon, Inc. PowerShot A70 (ptp)
Bus 002 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000

Abstrakte Kunst

Nachdem Udev seine Arbeit getan hat, kommt der Hardware Abstraction Layer HAL ins Spiel. Der Grundgedanke dabei: Anwendungen sollen auch ohne spezifischen Kenntnisse von deren Interna auf eine bestimmte Hardware zugreifen können. HAL dient hier als Schnittstelle zwischen der Hardware und den Anwendungen: Er sammelt Informationen über angeschlossene Hardware und stellt diese in einer genormten, von der Hardware abstrahierten Form den Anwendungen zur Verfügung.

Dazu bedient sich HAL verschiedener Quellen. Zum einen horcht er direkt auf den Systembussen, zum anderen bezieht er seine Informationen von Udev, dem Kernel sowie bestimmten systemweiten und benutzerspezifischen Konfigurationsdateien. Zusätzliche Informationen lagern in FDI-Dateien unter /usr/share/hal/fdi/information/ im XML-Format.

Hier finden sich für verschiedene Geräteklassen – etwa CD/DVD-Brenner oder Digicams – lange Listen mit entsprechenden Informationen über die Geräte einzelner Hersteller. Das ermöglicht es HAL, umfangreiche Informationen über die Hardware bereit zu stellen. Möchten Sie die vorhandenen Informationen sehen, verwenden Sie hierzu entweder den Konsolenbefehl lshal oder grafische Frontends wie hal-device-manager (Abbildung 4), gnome-device-manager und kde-hal-device-manager.

Abbildung 4: Der Hal-device-manager zeigt alle Informationen von HAL an.

HAL wird vom Freedesktop.org-Projekt [2] weiterentwickelt. Die Software läuft als Daemon hald im Hintergrund. Darüber hinaus startet sie bei Bedarf einige Hilfsdienste, die in den Prozesslisten meist mit hald-addon- beginnen und dazu dienen, den Status bestimmter Geräte zu überwachen. Findet sich ein Prozess, den das System mit hald-addon-storage: polling /dev/hda angezeigt, dann bedeutet dies, dass dieser das Gerät abfragt, das hinter /dev/hda steht. In Beispiel handelt es sich um das CD/DVD-Laufwerk.

Mit dem Bus zur Arbeit

Zwar stellt HAL die Geräteinformationen für die Anwendungen bereit, jedoch kommuniziert es nicht direkt mit ihnen. Hier kommt D-Bus ins Spiel: D-Bus unterliegt ebenfalls der Obhut von Freedesktop.org und arbeitet sehr eng mit HAL zusammen. Bei D-Bus handelt es sich um ein so genanntes IPC-Framework. Es ist auf die Bedürfnisse von Desktopanwendungen ausgerichtet und kommt inzwischen bei fast jeder Linux-Distribution mit zum Einsatz. Hierbei dient D-Bus einerseits der Kommunikation zwischen zwei Desktopanwendungen innerhalb derselben Desktop-Session und andererseits der Kommunikation zwischen einer Desktopanwendung und dem Betriebssystem bzw. seinen Komponenten.

Der Idee des IPC-Framework gibt es schon seit einiger Zeit: Beide großen Desktops, Gnome und KDE, haben in früherer Zeit intensiv mit verschiedenen Ansätzen gearbeitet: Gnome in erster Linie mit Corba [3] und KDE mit DCOP [4]. Auch Windows kennt IPC und nutzt das selbstentwickelte DCOM [5]. Im Übrigen existieren auch weitere IPC-Mechanismen unter Linux. Diese beschränken sich aber auf bestimmte andere Aufgaben.

D-Bus läuft ebenfalls als Daemon und stellt zwei Kommunikationskanäle ("Busse") bereit: Der System-Bus startet direkt beim Booten und steht unabhängig vom Anmelden eines Benutzers am grafischen System bereit; er läuft also permanent. Meldet sich ein Benutzer an der grafischen Oberfläche an, startet ein weiterer Bus: der Session-Bus. Hierzu kennt der Daemon-Prozess dbus-daemon zwei Optionen, einmal --system und zum anderen --session.

Während der Daemon-Prozess für den Systembus seine Konfigurationsparameter aus /etc/dbus-1/system.conf bezieht, liest der Session-Bus die Datei /etc/dbus-1/session.conf aus. Zum Starten des Daemons selbst kommt übrigens das Programm dbus-launch zum Einsatz. Während einer grafischen Benutzer-Session läuft Dbus-launch permanent als Daemon, um bei Bedarf weitere Session-Bus-Prozesse zu starten. Nach dem Abmelden des Benutzers beenden sich Dbus-launch und der passende Session-Bus, so dass nur noch der System-Bus übrig bleibt. Die Abbildungen 5 und 6 zeigen die Zusammenhänge.

Abbildung 5: Während der Systembus D-Bus permanent läuft, starten der D-Bus-Launcher und der Session-Bus nur für die Zeit einer Benutzersession.
Abbildung 6: HAL organisiert die Informationen über angeschlossene Hardware und stellt diese mittels D-Bus den Applikationen bereit.

Fahrkarte bitte!

Meldet sich eine Applikation nun für eine bestimmte Geräteklasse (beispielsweise camera oder storage) an, informiert HAL über D-Bus das Programm, sobald sich der Status eines Gerätes in dieser Klasse ändert. So startet zum Beispiel der Gnome-volume-manager das Importprogramm gthumb-import, wenn Sie eine Kamera anschließen (Abbildung 7).

Abbildung 7: Im Tool Gnome-volume-properties legen Sie das Verhalten für den Gnome-volume-manager so fest, dass dieser Gthumb-import startet, sobald Sie eine Digitalkamera anschließen.

Unter KDE 4 findet sich in der Kontrollleiste ein Miniprogramm in Form eines Laptop-Symbols mit dem Titel Geräteüberwachung. Es arbeitet mit D-Bus zusammen und zeigt neu angeschlossene Hardware an. Gleichzeitig erlaubt es Ihnen, je nach Gerät eine vorbestimmte Aktion zu aktivieren. So startet zum Beispiel beim Anschließen eines USB-Sticks auf Wunsch der neue Dolphin-Dateimanager, um den Inhalt des Sticks anzuzeigen.

Das Framework Solid konfigurieren Sie über die Systemeinstellungen. Das Einbinden der Hardware haben die Entwickler allerdings bisher nur für das Verwalten von HAL, des Netzwerks sowie von Bluetooth implementiert.

Fazit

War das Einbinden von Hardware unter Linux vor wenigen Jahren für viele Einsteiger noch ein Grund, Abstand zu nehmen, so bietet Linux inzwischen ein komfortables Gerätemanagement, das mit dynamisch zur Laufzeit angeschlossenen Geräten problemlos klarkommt. Neben USB-Geräten – dazu zählen auch WLAN-Sticks, Digitalkameras und sogar Camcorder – versteht es Linux auch, auf anderen Schnittstellen wie etwa Bluetooth und Firewire zu lauschen und bei Bedarf ein angeschlossenes Gerät nicht nur automatisch ins System einzubinden, sondern auch die passende Applikation zu starten.

Glücklicherweise bestehen seit kürzerer Zeit Tendenzen zur Vereinheitlichung der dahinterliegenden Technologien. Hat Udev den Vorgänger Devfs bereits seit längerem verdrängt und seinen Weg in den Linux-Kernel gefunden, setzt sich nun das von Freedesktop.org entwickelte Gespann HAL und D-Bus gegen die vormals favorisierten Lösungsansätze von Gnome (Corba) und KDE (DCOP) durch.

Dieses Zusammengehen kommt natürlich der Kommunikation zwischen den beiden Desktop-Umgebungen zugute. Während Gnome mit dem Gnome-volume-manager und seinen Hilfsprogrammen bereits ein ausgereiftes Frontend zum dynamischen Verwalten der Geräte bereitstellt, zieht KDE mit dem umfangreichen Umstrukturieren seiner Bibliotheken in Version 4 nach. Mit Solid kommt ein neues, leistungsfähiges Framework ins Spiel, das dafür sorgt, dass das Verwalten der Hardware unter KDE so komfortabel wie nie zuvor gelingt. Beim Thema dynamische Geräteverwaltung ist das Ende der Fahnenstange aber noch lange nicht erreicht.

[1] Udev-Regeln erstellen: Heike Jurzik, "Geräteschuppen", LinuxUser 12/2007, S. 96, http://www.linux-user.de/ausgabe/2007/12/096-udev/

[2] Freedesktop.org: http://www.freedesktop.org/wiki

[3] Corba: http://de.wikipedia.org/wiki/CORBA

[4] KDE-Aufgaben automatisieren mit DCOP: Daniel Molkentin, "Sprich mit mir", LinuxUser 02/2005, S. 39, http://www.linux-user.de/ausgabe/2005/02/039-dcop/

[5] DCOM für Programmierer: http://msdn.microsoft.com/en-us/library/ms809311.aspx

LinuxCommunity kaufen

Einzelne Ausgabe
 
Abonnements
 

Ähnliche Artikel

  • Hotplugging mit Udev, HAL und D-Bus
    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.
  • Geräteschuppen
    Udev heißt das Zauberwort, wenn's um Hardware geht: Das Programm räumt den Linux-Geräteschuppen so richtig auf.
  • Udev-Discover
    Der Open-Source-Entwickler José Félix Ontañón hat eine GUI-Anwendung namens Udev-Discover geschrieben, mit der sich Hardwareinformationen durchblättern lassen.
  • Linux über Udev angreifbar
    Mit dem Udev-Subsystem ermöglicht der Linux-Kernel im Zusammenspiel mit einem Userland-Programm dynamisch Gerätedateien anzulegen und wieder zu entfernen. Nun wurde bekannt, dass der Kommunikationskanal zwischen beiden nicht auf Authentizität prüft. So können User Rootrechte erhalten.
  • Auf den Zahn gefühlt
    Solange alles funktioniert, sind die genauen Details der Hard- und Software oft nebensächlich. Bei der Analyse von Problemen und der Treibersuche erweisen sich Systeminformationen jedoch als wertvolle Helfer.
Kommentare

Infos zur Publikation

title_2014_08

Digitale Ausgabe: Preis € 5,95
(inkl. 19% MwSt.)

Mit der Zeitschrift LinuxUser sind Sie als Power-User, Shell-Guru oder Administrator im kleinen Unternehmen monatlich auf dem aktuelle Stand in Sachen Linux und Open Source.

Sie sind sich nicht sicher, ob die Themen Ihnen liegen? Im Probeabo erhalten Sie drei Ausgaben zum reduzierten Preis. Einzelhefte, Abonnements sowie digitale Ausgaben erwerben Sie ganz einfach in unserem Online-Shop.

NEU: DIGITALE AUSGABEN FÜR TABLET & SMARTPHONE

HINWEIS ZU PAYPAL: Die Zahlung ist auch ohne eigenes Paypal-Konto ganz einfach per Kreditkarte oder Lastschrift möglich!       

Tipp der Woche

Schnell Multi-Boot-Medien mit MultiCD erstellen
Schnell Multi-Boot-Medien mit MultiCD erstellen
Tim Schürmann, 24.06.2014 12:40, 0 Kommentare

Wer mehrere nützliche Live-Systeme auf eine DVD brennen möchte, kommt mit den Startmedienerstellern der Distributionen nicht besonders weit: Diese ...

Aktuelle Fragen

Server antwortet mit falschem Namen
oin notna, 21.07.2014 19:13, 0 Antworten
Hallo liebe Community, Ich habe mit Apache einen Server aufgesetzt. Soweit, so gut. Im Heimnet...
o2 surfstick software für ubuntu?
daniel soltek, 15.07.2014 18:27, 1 Antworten
hallo zusammen, habe mir einen o2 surfstick huawei bestellt und gerade festgestellt, das der nic...
Öhm - wozu Benutzername, wenn man dann hier mit Klarnamen angezeigt wird?
Thomas Kallay, 03.07.2014 20:30, 1 Antworten
Hallo Team von Linux-Community, kleine Zwischenfrage: warum muß man beim Registrieren einen Us...
openSUSE 13.1 - Login-Problem wg. Fehler im Intel-Grafiktreiber?
Thomas Kallay, 03.07.2014 20:26, 8 Antworten
Hallo Linux-Community, habe hier ein sogenanntes Hybrid-Notebook laufen, mit einer Intel-HD460...
Fernwartung für Linux?
Alfred Böllmann, 20.06.2014 15:30, 7 Antworten
Hi liebe Linux-Freunde, bin beim klassischen Probleme googeln auf www.expertiger.de gestoßen, ei...