Interprozesskommunikation mit D-Bus und HAL

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.