Software::Kernel
Kernel D-Bus nimmt neuen Anlauf
Nach zwei vergeblichen Versuchen, eine Implementierung des Protokolls D-Bus in den Linux-Kernel zu bekommen, könnte der dritte Versuch alles richtig machen.
Larry Ewing
D-Bus ist ein Nachrichtenbus-System, mit dem Anwendungen auf einfache Weise miteinander kommunizieren können. Es stellt sowohl einen System-Daemon (für Ereignisse wie »neues Gerät hinzugefügt« oder »Druckwarteschlange geändert« als auch einen Sitzungs-Daemon pro eingeloggtem Benutzer (für allgemeine IPC zwischen Anwendungen) bereit. D-Bus wurde unter dem Dach von
freedesktop.org entwickelt und ist mindestens seit 2005 ein Standard für Linux-Systeme.
Während D-Bus sich zur Steuerung von Anwendungen bewährt hat, ist es zur Übertragung von nennenswerten Datenmengen nicht geeignet, da es nicht effizient genug ist. Es ist so gesehen keine vollständig brauchbare Interprozess-Kommunikation. Diese existiert unter Linux zwar in Form von anderen Mechanismen, aber konkurrierende Systeme einschließlich Android sind hierbei bereits weiter und bringen eine vollständige und leichter zu programmierende Implementation mit.
Um das Problem mit D-Bus zu lösen, kann man das Protokoll in den Kernel verlagern. Das wurde bereits zweimal versucht, aber beide Male aus technischen Gründen abgelehnt. So wurde eine Implementation im Netzwerkstack als zu invasiv zurückgewiesen. Eine neue Implementation von Lennart Poettering, Kay Sievers und Daniel Mack, die von Greg Kroah-Hartman unterstützt wird, hat aber bessere Aussichten. Lennart Poettering stellte sie in einem Vortrag auf der linux.conf.au, bei der er ein »Open Source Tea Party«-Shirt trug, vor.
Poettering erläuterte in seinem Vortrag zunächst, warum eine Implementation im Kernel sinnvoll ist. D-Bus als Daemon sei zu langsam für große Datenmengen, es werden keine Zugriffsrechte-Informationen mit übertragen, ebenso fehlen Zeitstempel. Es ist in der frühen Bootphase nicht verfügbar, die Verbindung mit Sicherheits-Frameworks wie SELinux erfolgt in Benutzerprozessen und es gibt Race-Conditions bei der Aktivierung von Diensten. Die starke Verwendung von XML ist dagegen Geschmackssache. Alles in allem sei D-Bus aber ein Erfolg und besitze ein solides Design.
Die Kernel-Implementation kdbus soll mit all den genannten Problemen aufräumen und die effiziente Übertragung von Datenmengen selbst im Gigabyte-Bereich ermöglichen. kdbus wurde als Gerätetreiber implementiert, um den Netzwerkstack zu umgehen. Namen werden ähnlich wie beim bisherigen D-Bus registriert, und Nachrichten besitzen einen Timeout.
Speziell für kdbus wurde der memfd-Mechanismus entwickelt. Dieser ermöglicht das Übertragen von Nachrichten ohne Kopieren, nur im ungünstigsten Fall sind zwei Kopiervorgänge nötig. memfs hat Ähnlichkeiten mit Shared Memory, das mit mmap allokiert wurde, da es über einen Dateideskriptor verwaltet wird. Dieser Deskriptor kann jedoch »versiegelt« werden, wonach sein Inhalt nicht mehr änderbar ist. Android besitzt einen ähnlichen Mechanismus namens »ashmem«. Nachrichten werden erst versiegelt und dann verschickt, das Senden lässt sich so beliebig oft wiederholen.
Ein Proxy-Server, der als Daemon-Prozess läuft, kann den bisherigen D-Bus-Daemon ersetzen und für die Kompatibilität mit Anwendungen sorgen, die noch nicht das kdbus-API benutzen. Es wird sicher noch eine Weile dauern, bis einige Anwendungen umgestellt sind, wenn es überhaupt dazu kommt. Poettering hofft, dass kdbus im Laufe des Jahres in den Kernel einfließt, doch die Diskussion darüber hat noch gar nicht richtig begonnen. Momentan fehlen jedenfalls noch alle Sicherheitsmechanismen, der Rest soll jedoch nach Aussage von Poettering schon funktionieren.
){kind=small}
