D-Bus is an IPC mechanism designed for applications and services, with the aim of providing:
- Reliability of message delivery.
- Globally consistent message ordering.
- Providing broadcast notifications of changes.
- If you're using kdbus, trust of the identity of the message sender.
D-Bus is not designed for:
Bulk transport of data:
For that you may want to use a pipe or regular file descriptor.
Turning Linux into a microkernel.
Microkernels are known for having very fast IPC, and do every operation by sending a message to some other component.
It is tempting to build microkernel semantics on top of Linux by having services react to messages and perform the required actions, rather than using system calls.
The overhead involved in using D-Bus is too great for this.
At its core, D-Bus is a message bus, with subscription semantics so you get event notifications, and a serialisation/marshalling mechanism to provide a type system for messages.
Built on top of this is an object model, where applications sit in an event loop, responding to messages to call methods or read properties of virtual objects, in the object oriented sense.
Application frameworks often build on top of this to provide proxy objects, so that you can effectively refer to objects in different processes.
By providing a well known name where a D-Bus object may be found, you can have local services provide an API for performing operations, and local applications instruct these services to perform operations.
A more detailed description of what D-Bus is and its concepts,
can be found here.
The article is about sd-bus, but the "What is D-Bus again?" and
"Introduction to D-Bus Concepts" sections are relevant to understanding D-Bus.