D-Bus

Last updated
Desktop Bus
Developer(s) Red Hat
Initial releaseNovember 2006;17 years ago (2006-11)
Stable release
1.14.10 / September 1, 2023;13 months ago (2023-09-01) [1]
Preview release
1.15.8 / August 21, 2023;14 months ago (2023-08-21) [2]
Repository
Written in C
Operating system Cross-platform
Predecessor CORBA
DCOP
Type
License GPLv2+ or AFL  2.1 [3]
Website www.freedesktop.org/wiki/Software/dbus

D-Bus (short for "Desktop Bus" [4] ) is a message-oriented middleware mechanism that allows communication between multiple processes running concurrently on the same machine. [5] [6] D-Bus was developed as part of the freedesktop.org project, initiated by GNOME developer Havoc Pennington to standardize services provided by Linux desktop environments such as GNOME and KDE. [7] [8] [ dead link ]

Contents

The freedesktop.org project also developed a free and open-source software library called libdbus, as a reference implementation of the specification. This library should not be confused with D-Bus itself, as other implementations of the D-Bus specification also exist, such as GDBus (GNOME), [9] QtDBus (Qt/KDE), [10] dbus-java [11] and sd-bus (part of systemd). [12]

Overview

D-Bus is an inter-process communication (IPC) mechanism initially designed to replace the software component communications systems used by the GNOME and KDE Linux desktop environments (CORBA and DCOP respectively). [13] [14] The components of these desktop environments are normally distributed in many processes, each one providing only a few—usually one—services. These services may be used by regular client applications or by other components of the desktop environment to perform their tasks. [15]

Processes without D-Bus.svg
Processes without D-Bus
Processes with D-Bus.svg
The same processes with D-Bus
Large groups of cooperating processes demand a dense mesh of individual communication channels (using one-to-one IPC methods) between them. D-Bus simplifies the IPC requirements with one single shared channel.

D-Bus provides a software-bus abstraction that gathers all the communications between a group of processes over a single shared virtual channel. [6] Processes connected to a bus do not know how it is internally implemented, but D-Bus specification guarantees that all processes connected to the bus can communicate with each other through it. D-Bus incurs at least a 2.5x performance loss over one-to-one IPC. [16]

Linux desktop environments take advantage of the D-Bus facilities by instantiating multiple buses, notably: [17] [6] [18]

A process can connect to any number of buses, provided that it has been granted access to them. In practice, this means that any user process can connect to the system bus and to its current session bus, but not to another user's session buses, or even to a different session bus owned by the same user. The latter restriction may change in the future if all user sessions are combined into a single user bus. [19]

D-Bus provides additional or simplifies existing functionality to the applications, including information-sharing, modularity and privilege separation. For example, information on an incoming voice-call received through Bluetooth or Skype can be propagated and interpreted by any currently-running music player, which can react by muting the volume or by pausing playback until the call is finished. [20]

D-Bus can also be used as a framework to integrate different components of a user application. For instance, an office suite can communicate through the session bus to share data between a word processor and a spreadsheet.

D-Bus specification

Bus model

Every connection to a bus is identified in the context of D-Bus by what is called a bus name. [5] A bus name consists of two or more dot-separated strings of letters, digits, dashes, and underscores—a reverse domain name. An example of a valid bus name is org.freedesktop.NetworkManager. [6]

When a process sets up a connection to a bus, the bus assigns to the connection a special bus name called unique connection name. [18] [6] Bus names of this type are immutable—it is guaranteed they will not change as long as the connection exists—and, more importantly, they cannot be reused during the bus lifetime. [5] [18] [6] This means that no other connection to that bus will ever have assigned such unique connection name, even if the same process closes down the connection to the bus and creates a new one. Unique connection names are easily recognizable because they start with the otherwise forbidden colon character. [18] [6] An example of a unique connection name is :1.1553 (the characters after the colon have no particular meaning [18] ).

A process can ask for additional bus names for its connection, [18] provided that any requested name is not already being used by another connection to the bus. In D-Bus parlance, when a bus name is assigned to a connection, it is said the connection owns the bus name. [5] [18] In that sense, a bus name cannot be owned by two connections at the same time, but, unlike unique connection names, these names can be reused if they are available: a process may reclaim a bus name released—purposely or not—by another process. [5] [6]

The idea behind these additional bus names, commonly called well-known names, is to provide a way to refer to a service using a prearranged bus name. [18] [6] For instance, the service that reports the current time and date in the system bus lies in the process whose connection owns the org.freedesktop.timedate1 bus name, regardless of which process it is.

Bus names can be used as a simple way to implement single-instance applications (second instances detect that the bus name is already taken). [18] It can also be used to track a service process lifecycle, since the bus sends a notification when a bus name is released due to a process termination. [18]

Object model

Because of its original conception as a replacement for several component oriented communications systems, D-Bus shares with its predecessors an object model in which to express the semantics of the communications between clients and services. The terms used in the D-Bus object model mimic those used by some object oriented programming languages. That does not mean that D-Bus is somehow limited to OOP languages—in fact, the most used implementation (libdbus) is written in C, a procedural programming language.

Browsing the existing bus names, objects, interfaces, methods and signals in a D-Bus bus using D-Feet D-Feet.png
Browsing the existing bus names, objects, interfaces, methods and signals in a D-Bus bus using D-Feet

In D-Bus, a process offers its services by exposing objects. These objects have methods that can be invoked, and signals that the object can emit. [18] Methods and signals are collectively referred to as the members of the object. [5] Any client connected to the bus can interact with an object by using its methods, making requests or commanding the object to perform actions. [18] For instance, an object representing a time service can be queried by a client using a method that returns the current date and time. A client can also listen to signals that an object emits when its state changes due to certain events, usually related to the underlying service. An example would be when a service that manages hardware devices—such as USB or network drivers—signals a "new hardware device added" event. Clients should instruct the bus that they are interested in receiving certain signals from a particular object, since a D-Bus bus only passes signals to those processes with a registered interest in them. [6]

A process connected to a D-Bus bus can request it to export as many D-Bus objects as it wants. Each object is identified by an object path, a string of numbers, letters and underscores separated and prefixed by the slash character, called that because of their resemblance to Unix filesystem paths. [5] [18] The object path is selected by the requesting process, and must be unique in the context of that bus connection. An example of a valid object path is /org/kde/kspread/sheets/3/cells/4/5. [18] However, it is not enforced—but also not discouraged—to form hierarchies within object paths. [6] The particular naming convention for the objects of a service is entirely up to the developers of such service, but many developers choose to namespace them using the reserved domain name of the project as a prefix (e.g. /org/kde). [18]

Every object is inextricably associated to the particular bus connection where it was exported, and, from the D-Bus point of view, only lives in the context of such connection. Therefore, in order to be able to use a certain service, a client must indicate not only the object path providing the desired service, but also the bus name under which the service process is connected to the bus. [5] This in turn allows that several processes connected to the bus can export different objects with identical object paths unambiguously.

An interface specifies members—methods and signals—that can be used with an object. [18] It is a set of declarations of methods (including its passing and returning parameters) and signals (including its parameters) identified by a dot-separated name resembling the Java language interfaces notation. [18] [6] An example of a valid interface name is org.freedesktop.Introspectable. [6] Despite their similarity, interface names and bus names should not be mistaken. A D-Bus object can implement several interfaces, but at least must implement one, providing support for every method and signal defined by it. The combination of all interfaces implemented by an object is called the object type. [5] [18]

When using an object, it is a good practice for the client process to provide the member's interface name besides the member's name, but is only mandatory when there is an ambiguity caused by duplicated member names available from different interfaces implemented by the object [5] [18] —otherwise, the selected member is undefined or erroneous. An emitted signal, on the other hand, must always indicate to which interface it belongs.

The D-Bus specification also defines several standard interfaces that objects may want to implement in addition to its own interfaces. [17] Although technically optional, most D-Bus service developers choose to support them in their exported objects since they offer important additional features to D-Bus clients, such as introspection. [6] These standard interfaces are: [17] [6]

The D-Bus specification defines a number of administrative bus operations (called "bus services") to be performed using the /org/freedesktop/DBus object that resides in the org.freedesktop.DBus bus name. [17] Each bus reserves this special bus name for itself, and manages any requests made specifically to this combination of bus name and object path. The administrative operations provided by the bus are those defined by the object's interface org.freedesktop.DBus. These operations are used for example to provide information about the status of the bus, [5] or to manage the request and release of additional well-known bus names. [17] [6]

Communications model

D-Bus was conceived as a generic, high-level inter-process communication system. To accomplish such goals, D-Bus communications are based on the exchange of messages between processes instead of "raw bytes". [5] [18] D-Bus messages are high-level discrete items that a process can send through the bus to another connected process. Messages have a well-defined structure (even the types of the data carried in their payload are defined), allowing the bus to validate them and to reject any ill-formed message. In this regard, D-Bus is closer to an RPC mechanism than to a classic IPC mechanism, with its own type definition system and its own marshaling. [5]

Example of one-to-one request-response message exchange to invoke a method over D-Bus. Here the client process invokes the SetFoo() method of the /org/example/object1 object from the service process named org.example.foo (or :1.14) in the bus. D-Bus method invocation.svg
Example of one-to-one request-response message exchange to invoke a method over D-Bus. Here the client process invokes the SetFoo() method of the /org/example/object1 object from the service process named org.example.foo (or :1.14) in the bus.

The bus supports two modes of interchanging messages between a client and a service process [5] :

Every D-Bus message consists of a header and a body. [18] The header is formed by several fields that identify the type of message, the sender, as well as information required to deliver the message to its recipient (destination bus name, object path, method or signal name, interface name, etc.). [18] [17] The body contains the data payload that the receiver process interprets—for instance the input or output arguments. All the data is encoded in a well known binary format called the wire format which supports the serialization of various types, such as integers and floating-point numbers, strings, compound types, and so on, [17] also referred to as marshaling.

The D-Bus specification defines the wire protocol: how to build the D-Bus messages to be exchanged between processes within a D-Bus connection. However, it does not define the underlying transport method for delivering these messages.

Internals

Most existing D-Bus implementations follow the architecture of the reference implementation. This architecture consists of two main components: [5]

D-Bus communications architecture - simple.svg
Process A and B have a one-to-one D-Bus connection using libdbus over a Unix domain socket. They can use it to exchange messages directly. [22] In this scenario bus names are not required. [18]
D-Bus communications architecture - message bus.svg
Process A and B both connected to a dbus-daemon using libdbus over a Unix domain socket. They can exchange messages sending them to the message bus process, which in turn will deliver the messages to the appropriate process. In this scenario bus names are mandatory to identify the destination process.

The libdbus library (or its equivalent) internally uses a native lower-level IPC mechanism to transport the required D-Bus messages between the two processes in both ends of the D-Bus connection. D-Bus specification does not mandate which particular IPC transport mechanisms should be available to use, as it is the communications library that decides what transport methods it supports. For instance, in Unix-like operating systems such as Linux libdbus typically uses Unix domain sockets as the underlying transport method, but it also supports TCP sockets. [5] [18]

The communications libraries of both processes must agree on the selected transport method and also on the particular channel used for their communication. This information is defined by what D-Bus calls an address. [6] [18] Unix-domain sockets are filesystem objects, and therefore they can be identified by a filename, so a valid address would be unix:path=/tmp/.hiddensocket. [5] [17] Both processes must pass the same address to their respective communications libraries to establish the D-Bus connection between them. An address can also provide additional data to the communications library in the form of comma-separated key=value pairs. [6] [17] This way, for example, it can provide authentication information to a specific type of connection that supports it.

When a message bus daemon like dbus-daemon is used to implement a D-Bus bus, all processes that want to connect to the bus must know the bus address, the address by which a process can establish a D-Bus connection to the central message bus process. [5] [18] In this scenario, the message bus daemon selects the bus address and the remainder processes must pass that value to their corresponding libdbus or equivalent libraries. dbus-daemon defines a different bus address for every bus instance it provides. These addresses are defined in the daemon's configuration files.

Two processes can use a D-Bus connection to exchange messages directly between them, [22] but this is not the way in which D-Bus is normally intended to be used. The usual way is to always use a message bus daemon (i.e. dbus-daemon) as a communications central point to which each process should establish its point-to-point D-Bus connection. When a process—client or service—sends a D-Bus message, the message bus process receives it in the first instance and delivers it to the appropriate recipient. The message bus daemon may be seen as a hub or router in charge of getting each message to its destination by repeating it through the D-Bus connection to the recipient process. [18] The recipient process is determined by the destination bus name in the message's header field, [17] or by the subscription information to signals maintained by the message bus daemon in the case of signal propagation messages. [6] The message bus daemon can also produce its own messages as a response to certain conditions, such as an error message to a process that sent a message to a nonexistent bus name. [18]

dbus-daemon improves the feature set already provided by D-Bus itself with additional functionality. For example, service activation allows automatic starting of services when needed—when the first request to any bus name of such service arrives at the message bus daemon. [5] This way, service processes neither need to be launched during the system initialization or user initialization stage nor need they consume memory or other resources when not being used. This feature was originally implemented using setuid helpers, [23] but nowadays it can also be provided by systemd's service activation framework.[ citation needed ] Service activation is an important feature that facilitates the management of the process lifecycle of services (for example when a desktop component should start or stop). [18]

History and adoption

D-Bus was started in 2002 by Havoc Pennington, Alex Larsson (Red Hat) and Anders Carlsson. [8] The version 1.0—considered API stable—was released in November 2006. [24] [25]

The dbus-daemon plays a significant role in modern Linux graphical desktop environments. Free and open-source-software display servers and UI toolkits.svg
The dbus-daemon plays a significant role in modern Linux graphical desktop environments.

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

One of the earlier adopters was the (nowadays deprecated) Hardware Abstraction Layer. HAL used D-Bus to export information about hardware that has been added to or removed from the computer. [8]

The usage of D-Bus is steadily expanding beyond the initial scope of desktop environments to cover an increasing amount of system services. For instance, the NetworkManager network daemon, BlueZ bluetooth stack and PulseAudio sound server use D-Bus to provide part or all of their services. systemd uses the D-Bus wire protocol for communication between systemctl and systemd, and is also promoting traditional system daemons to D-Bus services, such as logind. [27] Another heavy user of D-Bus is Polkit, whose policy authority daemon is implemented as a service connected to the system bus. [28]

Implementations

libdbus

Although there are several implementations of D-Bus, the most widely used is the reference implementation libdbus, developed by the same freedesktop.org project that designed the specification. However, libdbus is a low-level implementation that was never meant to be used directly by application developers, but as a reference guide for other reimplementations of D-Bus (such as those included in standard libraries of desktop environments, or in programming language bindings). The freedesktop.org project itself recommends applications authors to "use one of the higher level bindings or implementations" instead. [29] The predominance of libdbus as the most used D-Bus implementation caused the terms "D-Bus" and "libdbus" to be often used interchangeably, leading to confusion.[ citation needed ]

GDBus

GDBus [9] is an implementation of D-Bus based on GIO streams included in GLib, aiming to be used by GTK+ and GNOME. GDBus is not a wrapper of libdbus, but a complete and independent reimplementation of the D-Bus specification and protocol. [30] MATE Desktop [31] and Xfce (version 4.14), which are also based on GTK+ 3, also use GDBus.[ citation needed ]

sd-bus

In 2013, the systemd project rewrote libdbus in an effort to simplify the code, [32] but it also resulted in a significant increase of the overall D-Bus performance. In preliminary benchmarks, BMW found that the systemd's D-Bus library increased performance by 360%. [33] By version 221 of systemd, released in 2015, the sd-bus API was declared stable. [34]

kdbus

kdbus is implemented as a character device driver. All communication between processes take place over special character device nodes in /dev/kdbus (cf. devfs). Simplified Structure of the Linux Kernel.svg
kdbus is implemented as a character device driver. All communication between processes take place over special character device nodes in /dev/kdbus (cf. devfs).

kdbus was a project that aimed to reimplement D-Bus as a kernel-mediated peer-to-peer inter-process communication mechanism. Beside performance improvements, kdbus would have advantages arising from other Linux kernel features such as namespaces and auditing, [33] [37] security from the kernel mediating, closing race conditions, and allowing D-Bus to be used during boot and shutdown (as needed by systemd). [38] kdbus inclusion in the Linux kernel proved controversial, [39] and was dropped in favor of BUS1, as a more generic inter-process communication. [40]

Language bindings

Several programming language bindings for D-Bus have been developed, [41] such as those for Java, C#, Ruby, Rust and Perl.[ citation needed ]

See also

Related Research Articles

In computing, a desktop environment (DE) is an implementation of the desktop metaphor made of a bundle of programs running on top of a computer operating system that share a common graphical user interface (GUI), sometimes described as a graphical shell. The desktop environment was seen mostly on personal computers until the rise of mobile computing. Desktop GUIs help the user to easily access and edit files, while they usually do not provide access to all of the features found in the underlying operating system. Instead, the traditional command-line interface (CLI) is still used when full control over the operating system is required.

<span class="mw-page-title-main">Inter-process communication</span> How computer operating systems enable data sharing

In computer science, inter-process communication (IPC), also spelled interprocess communication, are the mechanisms provided by an operating system for processes to manage shared data. Typically, applications can use IPC, categorized as clients and servers, where the client requests data and the server responds to client requests. Many applications are both clients and servers, as commonly seen in distributed computing.

<span class="mw-page-title-main">CUPS</span> Computer printing system

CUPS is a modular printing system for Unix-like computer operating systems which allows a computer to act as a print server. A computer running CUPS is a host that can accept print jobs from client computers, process them, and send them to the appropriate printer.

freedesktop.org (fd.o), formerly X Desktop Group (XDG), is a project to work on interoperability and shared base technology for free-software desktop environments for the X Window System (X11) and Wayland on Linux and other Unix-like operating systems. Although freedesktop.org produces specifications for interoperability, it is not a formal standards body.

DesktopCommunicationProtocol (DCOP) was an inter-process communication (IPC) daemon by KDE used in K Desktop Environment 3. The design goal for the protocol was to allow applications to interoperate, and share complex tasks. Essentially, DCOP was a ‘remote control’ system, which allowed applications or scripts to enlist the help of other applications. DCOP is built on top of the X11 Inter-Client Exchange protocol.

<span class="mw-page-title-main">Scanner Access Now Easy</span> Open source scanner application programming interface

Scanner Access Now Easy (SANE) is an open-source application programming interface (API) that provides standardized access to any raster image scanner hardware. The SANE API is public domain. It is commonly used on Linux.

udev is a device manager for the Linux kernel. As the successor of devfsd and hotplug, udev primarily manages device nodes in the /dev directory. At the same time, udev also handles all user space events raised when hardware devices are added into the system or removed from it, including firmware loading as required by certain devices.

<span class="mw-page-title-main">Avahi (software)</span> Zero-configuration networking (zeroconf) implementation

Avahi is a free zero-configuration networking (zeroconf) implementation, including a system for multicast DNS and DNS Service Discovery. It is licensed under the GNU Lesser General Public License (LGPL).

<span class="mw-page-title-main">NetworkManager</span> Software

NetworkManager is a daemon that sits on top of libudev and other Linux kernel interfaces and provides a high-level interface for the configuration of the network interfaces.

<span class="mw-page-title-main">GNOME Keyring</span>

GNOME Keyring is a software application designed to store security credentials such as usernames, passwords, and keys, together with a small amount of relevant metadata. The sensitive data is encrypted and stored in a keyring file in the user's home directory. The default keyring uses the login password for encryption, so users don't need to remember another password.

<span class="mw-page-title-main">PulseAudio</span> Sound server for Unix-like operating systems

PulseAudio is a network-capable sound server program distributed via the freedesktop.org project. It runs mainly on Linux, including Windows Subsystem for Linux on Microsoft Windows and Termux on Android; various BSD distributions such as FreeBSD, OpenBSD, and macOS; as well as Illumos distributions and the Solaris operating system. It serves as a middleware in between applications and hardware and handles raw PCM audio streams.

HAL is a software subsystem for UNIX-like operating systems providing hardware abstraction.

A desktop environment is a collection of software designed to give functionality and a certain look and feel to an operating system.

<span class="mw-page-title-main">PackageKit</span> Free software

PackageKit is a free and open-source suite of software applications designed to provide a consistent and high-level abstraction layer for a number of different package management systems. PackageKit was created by Richard Hughes in 2007, and first introduced into an operating system as a default application in May 2008 with the release of Fedora 9.

GVfs is GNOME's userspace virtual filesystem designed to work with the I/O abstraction of GIO, a library available in GLib since version 2.15.1. It installs several modules that are automatically used by applications using the APIs of libgio. There is also FUSE support that allows applications not using GIO to access the GVfs filesystems.

<span class="mw-page-title-main">Jami (software)</span> Distributed multimedia communications platform

Jami is a SIP-compatible distributed peer-to-peer softphone and SIP-based instant messenger for Linux, Microsoft Windows, macOS, iOS, and Android. Jami was developed and maintained by the Canadian company Savoir-faire Linux, and with the help of a global community of users and contributors, Jami positions itself as a potential free Skype replacement.

<span class="mw-page-title-main">GIO (software)</span>

GIO is a library, designed to present programmers with a modern and usable interface to a virtual file system. It allows applications to access local and remote files with a single consistent API, which was designed "to overcome the shortcomings of GnomeVFS" and be "so good that developers prefer it over raw POSIX calls."

<span class="mw-page-title-main">Wayland (protocol)</span> Display system intended to replace X11

Wayland is a communication protocol that specifies the communication between a display server and its clients, as well as a C library implementation of that protocol. A display server using the Wayland protocol is called a Wayland compositor, because it additionally performs the task of a compositing window manager.

systemd Suite of system components for Linux

systemd is a software suite that provides an array of system components for Linux operating systems. The main aim is to unify service configuration and behavior across Linux distributions. Its primary component is a "system and service manager" — an init system used to bootstrap user space and manage user processes. It also provides replacements for various daemons and utilities, including device management, login management, network connection management, and event logging. The name systemd adheres to the Unix convention of naming daemons by appending the letter d. It also plays on the term "System D", which refers to a person's ability to adapt quickly and improvise to solve problems.

<span class="mw-page-title-main">UPower</span> Linux power management middleware

UPower is a piece of middleware for power management on Linux systems. It enumerates power sources, maintains statistics and history data on them and notifies about status changes. It consists of a daemon (upowerd), an application programming interface and a set of command line tools. The daemon provides its functionality to applications over the system bus. PolicyKit restricts access to the UPower functionality for initiating hibernate mode or shutting down the operating system (freedesktop.upower.policy). The command-line client program upower can be used to query and monitor information about the power supply devices in the system. Graphical user interfaces to the functionality of UPower include the GNOME Power Manager and the Xfce Power Manager.

References

  1. ↑ "D-Bus 1.14.x changelog" . Retrieved 30 December 2023.
  2. ↑ "NEWS file for current branch" . Retrieved 30 December 2023.
  3. ↑ Havoc's Blog July, 2007
  4. ↑ Ward, Brian (2004). "14: A brief survey of the Linux desktop". How Linux Works: What Every Superuser Should Know (2 ed.). San Francisco: No Starch Press (published 2014). p. 305. ISBN   9781593275679 . Retrieved 2016-11-07. One of the most important developments to come out of the Linux desktop is the Desktop Bus (D-Bus), a message-passing system. D-Bus is important because it serves as an interprocess communication mechanism that allows desktop applications to talk to each other [...].
  5. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Vermeulen, Jeroen (14 Jul 2013). "Introduction to D-Bus". FreeDesktop.org. Retrieved 22 October 2015.
  6. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Cocagne, Tom (August 2012). "DBus Overview". pythonhosted.org. Retrieved 22 October 2015.
  7. ↑ Vermeulen, Jeroen (14 Jul 2013). "Introduction to D-Bus". FreeDesktop.org. Retrieved 3 October 2015. D-Bus [...] is designed for use as a unified middleware layer underneath the main free desktop environments.
  8. 1 2 3 Palmieri, John (January 2005). "Get on D-BUS". Red Hat Magazine. Archived from the original on 23 October 2015. Retrieved 3 November 2015.
  9. 1 2 "gdbus". GNOME developer. Retrieved 4 January 2015.
  10. ↑ "QtDBus module". Qt Project. Retrieved 1 June 2015.
  11. ↑ "DBus-Java Documentation". FreeDesktop.org. Retrieved 4 January 2015.
  12. ↑ Poettering, Lennart (19 June 2015). "The new sd-bus API of systemd" . Retrieved 21 October 2015.
  13. ↑ Pennington, Havoc; Wheeler, David; Walters, Colin. "D-Bus Tutorial" . Retrieved 21 October 2015. For the within-desktop-session use case, the GNOME and KDE desktops have significant previous experience with different IPC solutions such as CORBA and DCOP. D-Bus is built on that experience and carefully tailored to meet the needs of these desktop projects in particular.
  14. ↑ Vermeulen, Jeroen (14 Jul 2013). "Introduction to D-Bus". FreeDesktop.org. Retrieved 3 October 2015. D-Bus was first built to replace the CORBA-like component model underlying the GNOME desktop environment. Similar to DCOP (which is used by KDE), D-Bus is set to become a standard component of the major free desktop environments for GNU/Linux and other platforms.
  15. ↑ "Desktop Environment - an overview | ScienceDirect Topics". www.sciencedirect.com. Retrieved 2023-08-24.
  16. ↑ Answer 7. "D-Bus FAQ" . Retrieved 2024-08-06.
  17. 1 2 3 4 5 6 7 8 9 10 11 12 13 Pennington, Havoc; Carlsson, Anders; Larsson, Alexander; Herzberg, Sven; McVittie, Simon; Zeuthen, David. "D-Bus Specification". Freedesktop.org. Retrieved 22 October 2015.
  18. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 Pennington, Havoc; Wheeler, David; Walters, Colin. "D-Bus Tutorial" . Retrieved 21 October 2015.
  19. ↑ Poettering, Lennart (19 June 2015). "The new sd-bus API of systemd" . Retrieved 21 October 2015. we are working on moving things to a true user bus, of which there is only one per user on a system, regardless how many times that user happens to log in
  20. 1 2 Love, Robert (5 January 2005). "Get on the D-BUS". Linux Journal . Retrieved 14 October 2014.
  21. ↑ "What is D-Bus?". FreeDesktop.org. Retrieved 29 October 2015. There are also some reimplementations of the D-Bus protocol for languages such as C#, Java, and Ruby. These do not use the libdbus reference implementation
  22. 1 2 "What is D-Bus?". FreeDesktop.org. Retrieved 29 October 2015. is built on top of a general one-to-one message passing framework, which can be used by any two apps to communicate directly (without going through the message bus daemon)
  23. ↑ "D-BUS System Activation". FreeDesktop.org. Retrieved 18 February 2016.
  24. ↑ Palmieri, John (9 Nov 2006). "[announce] D-Bus 1.0.0 "Blue Bird" released". dbus (Mailing list).
  25. 1 2 Molkentin, Daniel (12 November 2006). "D-Bus 1.0 "Blue Bird" Released". KDE News. Retrieved 3 November 2015.
  26. ↑ Seigo, Aaron. "Introduction To D-BUS". KDE TechBase. Retrieved 3 November 2015.
  27. ↑ Poettering, Lennart (19 June 2015). "The new sd-bus API of systemd" . Retrieved 21 October 2015. Since systemd's inception it has been the IPC system it exposes its interfaces on.
  28. ↑ "Polkit reference manual". FreeDesktop.org. Retrieved 3 November 2015.
  29. ↑ "What is D-Bus?". FreeDesktop.org. Retrieved 5 January 2015. The low-level implementation is not primarily designed for application authors to use. Rather, it is a basis for binding authors and a reference for reimplementations. If you are able to do so it is recommended that you use one of the higher level bindings or implementations.
  30. ↑ "Migrating to GDBus". GNOME Developer. Retrieved 21 October 2015. dbus-glib uses the libdbus reference implementation, GDBus doesn't. Instead, it relies on GIO streams as transport layer, and has its own implementation for the D-Bus connection setup and authentication.
  31. ↑ "MATE: Roadmap". Archived from the original on 29 July 2019. Retrieved 31 January 2019.
  32. ↑ Poettering, Lennart (20 Mar 2013). "[HEADSUP] libsystemd-bus + kdbus plans". systemd-devel (Mailing list).
  33. 1 2 Edge, Jake (30 May 2013). "ALS: Linux inter-process communication and kdbus". LWN.net . Retrieved 21 October 2015.
  34. ↑ Poettering, Lennart (19 Jun 2015). "[ANNOUNCE] systemd v221". systemd-devel (Mailing list).
  35. ↑ "The unveiling of kdbus". LWN.net. 2014-01-13.
  36. ↑ "Documentation/kdbus.txt (from the initial patch set)". LWN.net. 2014-11-04.
  37. ↑ Corbet, Jonathan (13 January 2014). "The unveiling of kdbus". LWN.net . Retrieved 11 April 2014.
  38. ↑ Kroah-Hartman, Greg (13 Apr 2015). "[GIT PULL] kdbus for 4.1-rc1". linux-kernel (Mailing list).
  39. ↑ Corbet, Jonathan (22 April 2015). "The kdbuswreck". LWN.net . Retrieved 29 June 2015.
  40. ↑ "Keynote: A Fireside Chat with Greg Kroah-Hartman, Linux Foundation Fellow". YouTube. 18 October 2016. Archived from the original on 2021-12-21.
  41. ↑ "D-Bus Bindings". FreeDesktop.org. Retrieved 5 January 2015.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.