Open Source im professionellen Einsatz
Linux-Magazin 05/2006
© photocase.com

© photocase.com

Interprozesskommunikation mit D-Bus und HAL

Flotte Verkehrsmittel

Endlich ist Schluss mit Corba! Gnome verabschiedet sich von dem Standardisierungsmonster und setzt auf das Prozess-Messaging-System D-Bus. Auch Kollege KDE ist dabei, umzustellen.

606

Keiner mag Programme, die ihren Arbeitstag als Einzelgänger in einer Ecke des Desktops verbringen, wenn sie eigentlich mit anderen zusammenarbeiten sollten. Das mindeste ist noch, dass sie mit anderen über Drag&Drop ihre Daten austauschen. Viele Anwender verlangen von ihren Programmen aber noch umfassendere Kommunikationsfähigkeiten: Natürlich soll die eben angesteckte USB-Festplatte allen laufenden Programmen zur Verfügung stehen. Das VoIP-Softphone soll beim Einstecken eines Headsets einfach von der neuen Hardware Gebrauch machen, und zwar am besten ohne Neustart.

Sprich mit ihr

Damit das alles und noch viel mehr funktioniert, braucht ein Linux-System ein Kommunikationssystem, das Desktop-Anwendungen untereinander und mit den darunter liegenden Schichten bis hin zu Kernel und Hardware verbindet. Für künftige Linux-Generationen soll dies nach dem Willen der Freedesktop-Entwickler D-Bus [1] leisten, das sich zur Hardware-Anbindung auf den Hardware Abstraction Layer (HAL) stützt [2].

D-Bus ist ein System für die Interprozesskommunikation (Inter Process Communication, IPC), es stellt die Infrastruktur bereit, damit sich Anwendungen untereinander und mit Teilen des Betriebssystems unterhalten können. Zwar gibt es bereits die Unix-IPC-Mechanismen, sie beschränken sich aber auf Signale, Pipes und so fort.

Das D-Bus-Konzept klingt bekannt, denn schon seit langem gibt es konkurrierende Ansätze, zum Beispiel Corba, Microsofts DCOM oder noch hundert weitere Projekte. Sowohl KDE als auch Gnome haben zu Beginn mit eigenen Corba-Implementierungen experimentiert. KDE setzt seit längerem auf das Eigengewächs DCOP, bei Gnome wirken die Corba-Altlasten noch in dem Komponentensystem Bonobo nach.

Nun kann man zu Corba stehen, wie man will, die meisten Entwickler, die nur eben mal eine Desktop-Anwendung programmieren möchten, sind damit überfordert. Selbst einfache Gnome-Applets setzen die eingehende Beschäftigung mit der komplizierten Komponenten-Architektur voraus. Entsprechend fristet Bonobo in Gnome schon seit einiger Zeit ein Schattendasein.

D-Bus sollte einfacher werden und beginnt entsprechend klein: Die grundlegende Bibliothek Libdbus stellt nur Funktionen für die Kommunikation zweier Applikationen zur Verfügung. Anwendungsentwickler machen von ihr normalerweise keinen Gebrauch. Für sie gibt es die auf dem Glib-API basierende Libdbus-Glib, die ein objektorientiertes C-API bereitstellt. Auf dieser Ebene erweitern sich die Fähigkeiten von D-Bus hin zu einem Bus-System - wie der Name bereits andeutet.

Der Serverprozess »dbus-daemon« läuft im Hintergrund und wartet auf Verbindungsanfragen von Anwendungen, die sich für bestimmte Ereignistypen registrieren, zum Beispiel das Ein- und Ausstecken von Hardware. Tritt das Ereignis ein, schickt der D-Bus-Daemon eine Nachricht über den Bus, und die Anwendungen reagieren entsprechend.

Systemweit oder pro Session

Prinzipiell gibt es auf Systemen, die D-Bus verwenden, zwei von je einem Serverprozess realisierte Busse: den System-Bus und den Session-Bus. Der System-Bus startet beim Booten und ist auch aktiv, wenn kein Benutzer eingeloggt ist. Erst beim grafischen Login einer Desktop-Session startet auch ein Serverprozess für den Session-Bus. Das Binary »dbus-daemon« kennt für die beiden Modi die Kommandozeilenparameter »--system« respektive »--session«.

Zum Starten des Daemon enthält das D-Bus-Paket das Programm »dbus-launch«, das unter anderem die nötigen Umgebungsvariablen setzt. Die meisten Distributionen starten damit den D-Bus-Daemon im Session-Modus zusammen mit der X-Session.

Abbildung 1 zeigt die Stellung beider Busse in der Kommunikation zwischen den Betriebssystem-Komponenten. Der Session-Bus ermöglicht Anwendungen, die zu einer Desktop-Sitzung gehören, miteinander zu sprechen. Das können durchaus auch Dienste sein, die zum Beispiel die Desktop-Umgebung zur Verfügung stellt. Der System-Bus ist in erster Linie dafür gedacht, dass Desktop-Programme mit den darunter liegenden Schichten kommunizieren. So kann eine Anwendung sich über den System-Bus für eine Hardwareklasse registrieren, zum Beispiel digitale Kameras.

Abbildung 1: D-Bus und HAL im Zusammenspiel mit den restlichen Komponenten eines Linux-Systems. Über den Session-Bus kommunizieren Anwendungen untereinander. Den System-Bus nutzen Programme, um sich via HAL über Hardware zu informieren.

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • D-Bus: Byte-Order-Durcheinander bringt Programme zum Absturz
  • Bus-Touristik

    Sobald der D-Bus einen eingesteckten USB-Stick meldet, startet ein Perl-Daemon automatisch ein Backup mit Progressanzeige auf dem Desktop.

  • Hallo, Dave

    Die Libhal verhindert, dass das Hardware-Management zu einer Odyssee im Weltall wird. Dieser Artikel verrät C-Kundigen, wie sie in eigenen Programmen die Libhal-API dafür nutzen, Geräte zu finden und sich über Veränderungen unterrichten zu lassen.

  • Geräteverwalter

    Seit Ende Juni ist Dev-FS nun endlich Geschichte: Nachdem es mehr als drei Jahre auf dem Abstellgleis rangierte, verdrängte sein Nachfolger Udev den Geräteverwalter jetzt endgültig aus dem Kernel. Das Linux-Magazin blickt dem Sieger unter die Haube.

  • Websockets

    Wer den Raspberry Pi über eine Android-App zum Tanz auffordern möchte, bringt am besten Websockets mit auf den Ball. Sie erleichtern die gepflegte Konversation mit dem graziösen Minirechner.

comments powered by Disqus

Ausgabe 08/2016

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.