Login
Newsletter
Werbung

Mo, 22. Juni 2015, 17:04

Software::Systemverwaltung

Poettering: Das neue sd-bus API von systemd

Mit der jetzt veröffentlichten Version 221 hat Systemd seinen eigenen D-Bus-Client für stabil erklärt und offeriert die Programmierschnittstelle auch anderen Projekten. Die Implementation soll einfacher zu benutzen und schneller sein als die Alternativen. Der Linie von Systemd folgend ist sie jedoch offiziell zunächst auf Linux beschränkt.

Lennart Poettering

Wikipedia

Lennart Poettering

Systemd enthielt schon seit längerem eine eigene Implementation der Client-Seite des D-Bus-Protokolls. Mit Version 221 wird die Implementation jetzt auch für andere Entwickler zugänglich gemacht. Zuvor hatten die Systemd-Entwickler keine Schnittstelle zur Verfügung gestellt, um ohne Probleme noch Änderungen vornehmen zu können. Lennart Poettering erklärt in einem längeren Beitrag nicht nur die neue, sd-bus genannte Schnittstelle, sondern auch die Hintergründe von D-Bus.

D-Bus ist ein allgemeines System zur Interprozesskommunikation für Linux und andere Betriebssysteme. Clients verbinden sich über einen Server miteinander. Das System beruht auf Konzepten wie Bussen, Objekten, Schnittstellen, Methoden, Signalen und Eigenschaften und bietet an Funktionalität Zugriffskontrolle, ein umfangreiches Typsystem, Entdeckung von Diensten, Introspektion, Dienstaktivierung, Schnittstellen zu vielen Programmiersprachen und einiges mehr. Es wird seit über zehn Jahren verbreitet eingesetzt.

D-Bus wird meist lokal verwendet, kann aber prinzipiell auch zwischen mehreren Rechnern genutzt werden. Da es keine eingebaute Verschlüsselung besitzt, sollte es nicht direkt über TCP, sondern besser über einen SSH-Tunnel betrieben werden. Systemd benutzt dieses Verfahren bereits. Obwohl D-Bus im Laufe der Jahre ein paar Schwächen erkennen ließ, hält Poettering das grundlegende Design für herausragend. Würde man heute ein neues IPC-System entwerfen, wäre es nicht viel anders als D-Bus.

D-Bus ist sowohl eine Spezifikation als auch eine Referenzimplementation. Auf der Server-Seite kommt nach wie vor ausschließlich die Referenzimplementation zum Einsatz. Ein alternativer Server ist mit kdbus in Arbeit, einer Implementation im Linux-Kernel, die hauptsächlich wegen technischer Bedenken, die aber lösbar sind, nicht in den neuen Kernel 4.1 aufgenommen wurde. Auf der Client-Seite gab es bisher hauptsächlich zwei Implementationen. Die Referenzimplementation ist sehr kompliziert und umständlich zu benutzen, aber portabel und leidet nie unter Speichermangel. GDBus ist an GLib angelehnt, einfacher zu benutzen und ebenfalls ziemlich portabel. Beide haben keinen Code gemeinsam, gelten aber als langsam.

Systemd fügte vor einiger Zeit eine dritte Implementation hinzu, die mit den beiden anderen keinen Code gemeinsam hat. Es ist eine Bibliothek auf sehr niedriger Ebene, die aber eine einfache Schnittstelle besitzt und dementsprechend einfach zu benutzen ist. sd-bus nutzt laut Poettering einige Linux-spezifische Funktionalität und ist dementsprechend wie Systemd selbst nicht als portable Software geplant. Es wurde darauf geachtet, dass es nie an Speichermangel leiden kann, und seine Geschwindigkeit soll die anderen Implementationen deutlich übertreffen. Doch letzteres war laut Poettering nicht das wesentliche Ziel der Neuentwicklung. Das Hauptargument für sd-bus ist, dass es kdbus, den Server-Code im Kernel, nutzen kann, wenn vorhanden. Bis kdbus tatsächlich offiziell im Kernel ist, hat das allerdings keine praktischen Auswirkungen.

Der Rest der Ankündigung gibt ein detailliertes Beispiel zur Nutzung von sd-bus. Die Ankündigung könnte auf manche Leser wie eine Reaktion auf die jüngste Diskussion um kdbus wirken, dürfte aber nicht damit im Zusammenhang stehen. sd-bus zeigt jedenfalls, dass das Argument der höheren Geschwindigkeit bei kdbus einer echten Grundlage entbehrt. Vielmehr wurde bereits festgestellt, dass schon eine Optimierung der Server-Software außerhalb des Kernels die Leistung wahrscheinlich so weit steigern könnte, wie es auch im Kernel möglich wäre. kdbus dürfte trotzdem eine neue Chance im Kernel erhalten, sobald die Entwickler eine überarbeitete Version vorlegen.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung