D-Bus and Friends: Making Linux “Just Work” on the Desktop John (J5) Palmieri Desktop Engineer

History of D-Bus ● Started in 2002 on freedesktop.org – Havoc Pennington, Alexander Larson, Anders Carlson ● Conceived as a common communication channel for the desktop – Buy in from both GNOME and KDE was a major goal

What is D-Bus? ● A local IPC mechanism ● Optimized for desktop communication – Session bus ● Enables system/session communication – System bus ● Peer to peer communication

Who uses D-Bus? ● Gnome – Fedora/Red Hat – Novell/SuSE – Debian – Nokia ● KDE – Limited support in Qt3 – Qt4 support being implemented (DCOP replacement?)

D-Bus and Friends Architecture in Fedora

Current Applications that use D-Bus in Fedora ● HAL ● NetworkManager ● desktop-printing (eggcups) ● cups-config-daemon ● gnome-volume-manager ● gfloppy

HAL

NetworkManager

desktop-printing & cups-config-daemon

gnome-volume-manager

Future D-Bus Applications ● oddjob – System administration tool by Nalin Dahyabhai ● Notification Bubbles ● Session Services – Augmenting gnome session ● System Services – Augmenting init

Future D-Bus Applications cont. ● Evolution integration – You’ve got mail – online/offline integration ● CORBA replacement in gnome-VFS ● XWindows – Static configuration files are so 90’s ● Package Installer – We’ve got MIME-types, why not use them?

More on Session Services ● Augments gnome-session ● Starts applications using D-Bus activation ● All desktop services are D-Bus aware or are provided by a D-Bus aware wrapper ● Dependency information makes sure services that are needed are loaded and in the right order ● Demo

Implications for System Services ● Take the Session Services idea and expand it to init ● Services started in parallel and with dependencies ● Some services are started when needed – cups-config-daemon is an ideal candidate – Dependency information applies to these services also ● Red Hat has an intern looking at this right now – He could use your help

The Pieces of D-Bus ● Bus’ – System and Session – Arbitrary ● Protocol – Header – Body ● Bindings – G-Lib, Qt, Python (and Twisted), Mono, Java?, Perl, Ruby, S- Lang, etc.

The Bus ● Bus’ run as daemons and route messages ● Connect to the bus – connection = dbus_bus_get (DBUS_BUS_SYSTEM, &error); ● Get a name on the bus – dbus_bus_request_name (connection, “org.foo.Bar”, 0, &error);

Protocol ● Unique Names vs Common Names – Unique Names (:1.02) – Common Name (org.foo.Bar) ● Header – Path, Interface, Member, Error Name, Reply Serial, Destination, Sender, Signature, (Details?) ● Body – The data

The Type System ● Basic Types – Byte, Boolean, (U)Int (16, 32, 64), Double, String ● Complex (recursive) Types – Array, Struct, Dict Entry, Varient ● Special Types – Object Path, Signature

Security ● ACL’s – Console user ● SELinux Integration – ImSep

Bindings ● Where users should be using D-Bus ● Main Bindings – Glib, Qt, Python, Mono ● Third Party Bindings – Ruby, Perl, S-Lang, C++, Java ● I maintain the Python Bindings and they are my favorite so lets write a quick server and client in Python ;-)

D-Bus 1.0 ● When – Soon – Sooner if you help out ● What’s Left to Do? – TODO – Write test cases, finalize the protocol, fix bugs – Finish bindings – Testing and Feedback (Qt4) – Documentation

For more info... ● D-Bus Website – ● Mailing List – ● Bugzilla – ● John (J5) Palmieri –