Introduction to the D-BUS messaging system

Havoc Pennington

Agenda

What is D-BUS?

Implementation details

How to use it

Status and how to help

Questions, Discussion

Problem at Hand

D-BUS attempts to solve two different problems with one codebase

System events:

Kernel -> Userspace

System daemons -> User sessions

IPC between desktop applications

System Events

Replaces filesystem polling, UNIX signals, and other sucky means of receiving notification from the kernel

Allows system daemons such as CUPS to send out notifications

Notifications are available to each logged-in user desktop

Example Systemwide Uses

gnome-volume-manager

CUPS and print monitor

IPSEC authentication

Bluetooth PIN

Wireless network events

Desktop IPC

Currently no way to write shared GNOME/KDE specs that require IPC

Many possibilities for standard desktop interfaces

Screensaver

Session management

Panel applets

Configuration system

Layer 1

Single app-to-app message-based IPC implemented in a library “libdbus”

Layer 2

Message bus is a special application that routes messages between other apps.

Daemon Implementation

Single daemon executable used for both system and session bus

However, there are two instances of the daemon running, one systemwide and one per-session

Configuration file passed to the daemon tunes behavior to each case

dbus-daemon-1 --system

dbus-daemon-1 --session

dbus-daemon-1 --config-file=/etc/dbus/system.conf

IPC Tradeoffs

Reliability: D-BUS is like TCP, not UDP

Connection state: Apps maintain a connection and can detect when the connection vanishes

Centralized: Message routing is done by a daemon on a single machine, not in distributed fashion

Binary: Binary protocol reduces bandwidth and parsing

Optimized for UNIX sockets, not the Internet

Inflexible; apps can't configure the tradeoffs

Protocol

Binary protocol with aligned data; no copying/parsing

Extending the Protocol

Add new types of message

Add new message flags

Add new header fields

Add custom data types

Types

INT32, UINT32, INT64, UINT64, BYTE, BOOL, DOUBLE

STRING (Unicode)

ARRAY of above

ARRAY of ARRAY of ...

OBJECT_PATH

CUSTOM (escape hatch, extension point)

DICT (probably a bad idea)

Security

Authentication establishes identity

Encryption of transport

Will extend auth negotiation to include SELinux identity

Test suite

Bus daemon has routing policies analagous to a firewall

Need a security audit

Bus Policies

Used only for systemwide bus, not user session bus

Messages denied by default; holes are punched to allow expected messages through

Policies can apply globally or only to connections by a specific user, group, or SELinux identity

Messages can be allowed through according to their type, method name, destination, sender, etc.

Implementation Attributes pt. 1

C library with opaque datatypes

No dependencies

Library size order of 200K, depending

Internal symbols not exported

75% of basic blocks run in “make check”

All errors handled including out of memory

Threadsafe

Implementation Attributes pt. 2

All operations can be done async/nonblocking

Loaded with assertions and “return if fail”

Portable

100% Doxygen coverage

Library designed for wrapping by GLib, Qt, scripting languages

Wrap-friendly features

Can associate extra data with each data type

Callback data has a free function to clean up closure

Can install an implementation vtable for threads, malloc, etc.

Not much “convenience bloat” in main lib

Type system designed to convert to native

Designed for integration with any main loop

Method invocation (pseudocode)

Connection c = bus_get (SESSION);

Message m = new Message;

m.set_destination (“org.kde.TextEditor”);

m.set_path (“/org/kde/TextEditor/documents/1”);

m.set_method (“GetText”);

Message r = c.send_with_reply_and_block (m);

String text = r.get_arg (1);

Proxy-based API (pseudocode)

Connection c = bus_get (SESSION);

Proxy p =

new Proxy (“org.kde.TextEditor”,

“/org/kde/TextEditor/documents/1”);

String text = p.GetText ();

Right Tool for the Job

Before using D-BUS, carefully consider how IPC tradeoffs should be resolved for your app

Do you want CORBA, MBUS, Spread, XML-RPC, SOAP, etc. instead?

If your communication isn't from system to users, or between desktop apps, then you will probably be using D-BUS either without the bus daemon, or with a custom bus daemon

Hardware Abstraction Layer

Abstracts hardware:

Converts linux kernel ABIs to something app developers have a hope of getting right

Abstracts differences between Linux and other systems

Unifies various kinds of hardware into single model

http://ometer.com/hardware.html

D-BUS lets apps track hardware changes

Work To Do

Updated todo lists at http://www.freedesktop.org/Software/dbus

GLib/Qt bindings not complete

Encryption and auth for TCP connections

Security audit

SELinux support

Finalize protocol

GNOME/KDE integration

Questions, Discussion

2003-11-09T21:26:27