D-Bus

From Wikipedia, the free encyclopedia
Jump to: navigation, search
D-Bus
Developer(s) Red Hat and the community
Stable release 1.8.0[1] / January 20, 2014; 2 months ago (2014-01-20)
Written in C
Operating system Cross-platform
Type
License GNU General Public License version 2 or later, or Academic Free License 2.1[2]
Website www.freedesktop.org/wiki/Software/dbus

D-Bus is a free and open-source inter-process communication (IPC) system, allowing multiple, concurrently-running computer programs (processes) to communicate with one another. It is mainly used by components of the freedesktop implementations such as GNOME, KDE SC or Xfce.

Heavily influenced by the DCOP system used by versions 2 and 3 of KDE, D-Bus has replaced DCOP in the KDE 4 release. An implementation of D-Bus supports most POSIX operating systems, and a port for Windows exists. It is used by Qt 4 and GNOME. In GNOME it has gradually replaced most parts of the earlier Bonobo mechanism.

D-Bus is developed as part of the freedesktop.org project.

Design[edit]

D-Bus is a message-bus system, a way for applications to talk to one another. D-Bus supplies both a system daemon (for events such as "new hardware device added" or "printer queue changed") and a per-user-login-session daemon (for general inter-process communication needs among user applications). The message bus builds on a general one-to-one message passing framework, which any two apps can use to communicate directly (without going through the message bus daemon). Most systems implement a privileged system channel, plus a private channel for each logged-in user, so that available information in the D-Bus registry can be restricted.

D-Bus works with Unix domain sockets between applications and daemons, so applications communicate with each other through a fork of the D-Bus daemon. However, as of January 2014 there is ongoing work on creating kdbus, which aims at replacing D-Bus by implementing a "peer-to-peer" inter-process communication (IPC) mechanism inside the Linux kernel, capable of routing messages between applications. Beside performance improvements, kdbus also offers various mechanisms inherited by already existing in-kernel features, including support for namespaces and auditing.[3][4]

Architecture[edit]

Example of usage in Linux-based systems. The dbus-daemon (named ubus in the illustration) is essentially at the core of the modern Linux graphical desktop environment. Binder is the counterpart used on Android.

D-Bus has three architectural layers:[5]

  • libdbus - a library that allows two applications to connect to each other and exchange messages; in 2013 the systemd project rewrote libdbus in an effort to simplify the code, but it turned out to significantly increase the performance of D-Bus as well. In preliminary benchmarks, BMW found that the systemd D-Bus library increased performance by 360%.[6]
  • dbus-daemon - a message-bus daemon executable, built on libdbus, that multiple applications can connect to. The daemon can route messages from one application to zero or more applications, thereby implementing the publish/subscribe paradigm.
  • wrapper libraries based on particular application frameworks

The design of D-Bus addresses two specific cases:

  • communication between desktop applications in the same desktop session; to allow integration of the desktop session as a whole, and address issues of the process lifecycle
  • communication between the desktop session and the operating system, where the operating system would typically include the kernel and any system daemons or processes

Mechanisms[edit]

Each application using D-Bus contains objects that usually map to GObject, QObject, C++ objects, or Python objects. Each D-bus object operates as an instance rather than as a type. Messages received over a D-Bus connection get routed to a specific object, not to the application as a whole. In this way, D-Bus resembles software componentry, as it appears to clients as if they are interacting with an object across the IPC connection, whether or not there is an object on the other side.

To allow messages to specify their destination object, the system needs a way to identify and address an object. For this purpose, D-Bus defines a name for each object. The name looks like a filesystem path, for example an object could have the name /org/kde/kspread/sheets/3/cells/4/5. D-Bus encourages human-readable paths, but developers are free to create an object named (e.g.) /com/mycompany/c5yo817y0c1y1c5b if it makes sense for their application.

The D-Bus objects' names are namespaced to help with independently developing code modules.[7] Namespaces are generally prefixed with the developer's reserved domain name components (e.g. /org/kde).

See also[edit]

References[edit]

  1. ^ "Announcing dbus 1.8.0". 2014-01-20. 
  2. ^ Havoc's Blog July, 2007
  3. ^ Jake Edge (2013-05-30). "ALS: Linux interprocess communication and kdbus". LWN.net. Retrieved 2014-04-11. 
  4. ^ Jonathan Corbet (2014-01-13). "The unveiling of kdbus". LWN.net. Retrieved 2014-04-11. 
  5. ^ "Get on the D-BUS". Linux Journal. Retrieved 2008-01-23. 
  6. ^ "ALS: Linux inter-process communication and kdbus". LWN.net. 2013-05-30. Retrieved 2013-11-13. 
  7. ^ "D-Bus Tutorial". 

External links[edit]