Off-topic: D-Bus in the kernel
alban.crequy at collabora.co.uk
Fri Sep 17 08:21:32 PDT 2010
Le Fri, 17 Sep 2010 16:04:55 +0200,
Mohamed Ikbel Boulabiar <boulabiar at gmail.com> a écrit :
> I have 2 questions:
> Anyone have tried performance improvements other than a simple
> ping-pong ?
I tested 3 performance tests and I listed them there:
I chose the ping-pong because this use-case shows the better
I also chose the Jabber connection on the N900 with Telepathy because it
is an user-oriented test and it generates a lot of D-Bus traffic between
the connection manager, the address book, the widgets on the desktop.
If you have an idea of sensible test, I can give it a try.
> Are we speaking about putting DBus in kernel by
> rethinking it's design and how it can be divided to kernelSpace +
> userSpace components ?
The protocol and semantic from the applications point of view didn't
change. It is just a new kind of socket supported, in addition to the
existing support for Unix sockets and TCP sockets. I think it is
important that no changes are required in applications. Only a small
patch in libdbus (6 files changed, 333 insertions(+), 1 deletions(-)).
The support for Unix/TCP sockets is not removed and will not be
deprecated: it will still be needed on non-Linux platforms and peer to
peer connections at least. dbus-daemon listens on AF_DBUS socket only
if the configuration file says so with <listen/>.
How to divide between kernel space and user space is a good question
and it is not decided. Here are my thoughts about the division and how
it is currently implemented in the kdbus prototype:
- Match rules and message dispatching: they need to be done in
kernel space. Otherwise we would still need to context switch to the
dispatcher (dbus-daemon) so there would be no gain.
- Security policy: I want to explore netlink to let dbus-daemon uploads
them to kdbus. At the moment, it is not implemented, so it is open
for all :-)
- Creating the buses: buses are still initiated from user land when
dbus-daemon listen() on an AF_DBUS socket. Nothing changes here
compared to other socket types.
- D-Bus activation: I am thinking to let dbus-daemon do that unless you
have a better proposition. The prototype deliver a message to
dbus-daemon when the recipient is a well-known name absent from the
bus. So the kernel module does not need to know the list of
activatable services. In this case, dbus-daemon wakes up but it is
not a performance problem.
- Client authentication: I don't know. At the moment, the prototype let
dbus-daemon handling that by delivering all messages which does not
look like a D-Bus message (i.e. the NULL byte and the commands like
"AUTH", "BEGIN", etc.) to dbus-daemon.
- The bus driver (who replies to D-Bus method calls to
org.freedesktop.DBus): I don't see the value to put this in the
kernel but I'm happy to be proven wrong. kdbus needs to know which
connection own which unique name and well-known name. In the
prototype, kdbus spies the "NameAcquired" and "NameLost" signals for
More information about the dbus