D-Bus

From Wikipedia, the free encyclopedia

This article may be too technical for a general audience. Please help improve this article by providing more context and better explanations of technical details to make it more accessible, without removing technical details.

D-Bus is a free software project which offers a simple way for applications to communicate with one another. It is developed by Red Hat as part of the freedesktop.org project.

D-Bus was heavily influenced by KDE2–3's DCOP system and has replaced it in the KDE 4 release; it is already implemented in Qt 4, GNOME, Windows, the maemo mobile platform, and the OLPC XO-1. In GNOME it has gradually replaced most parts of the earlier Bonobo mechanism.

[edit] Introduction

D-Bus (Desktop Bus) allows programs to register on it for offering services to others. It also offers client programs the possibility to look up which services are available. Programs can also register as waiting for events of the kernel like hot swapping hardware.

D-Bus is implemented as a daemon. Users can run several instances of it, each called a channel. There will usually be a privileged system channel, and a private instance for each logged in user. The private instances are required because the system channel has access restrictions.

The main mission of the system channel is to deliver the signals from the HAL daemon to the processes interested in them. The mission of the private instances is to provide unrestricted communication among any applications of the user.

[edit] Architecture

D-Bus is an inter-process communication (IPC) system^[2] with three architectural layers:

• A library, libdbus, that allows two applications to connect to each other and exchange messages.
• 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.
• Wrapper libraries based on particular application frameworks.

D-Bus is designed for 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 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.

[edit] Mechanisms

Each application using D-Bus contains objects, which generally (but not necessarily) map to GObject, QObject, C++ objects, or Python objects. An object is an instance rather than a type. When messages are received over a D-Bus connection, they are sent to a specific object, not to the application as a whole. In this way, D-Bus resembles software componentry, as it appears to the user as if an object is serialized across the IPC connection, no matter if there is an object on the other side or not.

To allow messages to specify their destination object, there has to be a way to refer to an object. In many programming languages, this is usually called a pointer or reference. However, these references are implemented as memory addresses relative to the address space of the application, and thus can't be passed from one application to another.

To solve this, D-Bus introduces a name for each object. The name looks like a filesystem path, for example an object could be named /org/kde/kspread/sheets/3/cells/4/5. Human-readable paths are preferred, but developers are free to create an object named /com/mycompany/c5yo817y0c1y1c5b if it makes sense for their application.

The D-Bus objects' names are namespaced to ensure different code modules are kept separated. Namespaces are generally prefixed with the developer's domain name components (eg. /org/kde).

[edit] Implementations

• Freedesktop.org D-Bus, reference implementation
• On-going Windows port of D-Bus
• NDesk Managed D-Bus, targeting the .NET framework, was the first independent implementation and follows cleanroom design^[3]
• D-Bus Java, evolved^[4] from a libdbus binding into an independent implementation

[edit] Examples

Most languages allow high-level access to D-Bus, hiding implementation details and optimizing marshalling, queuing and dispatching behind the scenes. In statically typed programming languages such as C# and Java, the interface to be used or exported must first be defined. To access HAL devices, a partial interface description in the C# language may look something like this:

For the device interface:

/* an Interface attribute is applied to mark the D-Bus interface name */
[Interface ("org.freedesktop.Hal.Device")]
public interface Device
{
        /* event definitions map to D-Bus signals */
        event PropertyModifiedHandler PropertyModified;
 
        /* properties and method calls map to D-Bus calls */
        /* the D-Bus type system is capable of representing generic dictionaries */
        IDictionary<string, object> AllProperties { get; }
 
        /* further methods and signals omitted for brevity */
}
 
/* D-Bus supports arbitrary structures */
public struct PropertyModification
{
        public string Key;
        public bool Added;
        public bool Removed;
}
 
public delegate void PropertyModifiedHandler (int modificationsLength,
                                        PropertyModification[] modifications);

For the device manager interface:

[Interface ("org.freedesktop.Hal.Manager")]
public interface Manager
{
        /* event definitions map to D-Bus signals */
        event Action<Device> DeviceAdded;
        event Action<Device> DeviceRemoved;
 
        /* properties and method calls map to D-Bus calls */
        Device[] AllDevices { get; }
        bool DeviceExists (Device udi);
        bool DeviceExists (ObjectPath udi);
        Device[] FindDeviceStringMatch (string key, string value);
        Device[] FindDeviceByCapability (string capability);
        void Remove (Device udi);
 
        /* further methods and signals omitted for brevity */
}

Once these interfaces have been defined, the programmer is able to obtain proxy objects mirroring remote counterparts and manipulate them directly as though they were in the local address space:

/* request a proxy object for the device manager from the system message bus */
Manager mgr = Bus.System.GetObject<Manager> ("org.freedesktop.Hal",
                                new ObjectPath ("/org/freedesktop/Hal/Manager"));
 
/* enumerate all devices */
foreach (Device dev in mgr.AllDevices) {
        /* print the path of the object  */
        Console.WriteLine (dev.ToString ());
 
        /* hook up to the PropertyModified signal of the device */
        dev.PropertyModified += delegate (int modificationsLength,
                                        PropertyModification[] modifications) {
                /* when properties are modified, print the changes */
                Console.WriteLine ("Properties changed on device {0}:", dev);
 
                foreach (PropertyModification modification in modifications)
                        Console.WriteLine (modification.Key);
        };
}

[edit] References

1. ^ Havoc's Blog July, 2007
2. ^ Get on the D-BUS. Linux Journal. Retrieved on 2008-01-23.
3. ^ Alp Toker, D-Bus mailing list (2006).
4. ^ Matthew Johnson, D-Bus mailing list (2007).

[edit] External links

Free software Portal

• Freedesktop.org D-Bus
• IBM's D-Bus tutorial
• How to pass a variant over D-Bus
• Examples of D-Bus usage from console