AF_BUS, D-Bus, and the Linux kernel

gregkh's picture

There's been a lot of information scattered around the internet about
these topic recently, so here's my attempt to put them all in one place
to (hopefully) settle things down and give my inbox a break.

Last week I spent a number of days at the GNOME Developer Hackfest
in Brussels, with the goal to help make the ability to distribute
applications written for GNOME (and even more generally, Linux) in a
better manner. A great summary of what happened there can be found in
this H-Online article. Also please read Alexander Larsson's
great summary of what we discussed
and worked on for another view of

Both of these articles allude to the fact that I'm working on putting
the D-Bus protocol into the kernel, in order to help achieve these
larger goals of proper IPC for applications. And I'd like to confirm
that yes, this is true, but it's not going to be D-Bus like you know it

Our goal (and I use "goal" in a very rough term, I have 8 pages of
scribbled notes describing what we want to try to implement here), is to
provide a reliable multicast and point-to-point messaging system for the
kernel, that will work quickly and securely. On top of this kernel
feature, we will try to provide a "libdbus" interface that allows
existing D-Bus users to work without ever knowing the D-Bus daemon was
replaced on their system.

nothing blocks

"But Greg!" some of you will shout, "What about the existing AF_BUS
kernel patches that have been floating around for a while and that you
put into the LTSI 3.4 kernel release?"

The existing AF_BUS patches are great for users who need a very
low-latency, high-speed, D-Bus protocol on their system. This includes
the crazy automotive Linux developers, who try to shove tens of
thousands of D-Bus messages through their system at boot time, all while
using extremely underpowered processors. For this reason, I included
the AF_BUS patches in the LTSI kernel release, as that limited
application can benefit from them.

Please remember the LTSI kernel is just like a distro kernel, it has no
relation to upstream kernel development other than being a consumer of
it. Patches are in this kernel because the LTSI member groups need
them, they aren't always upstream, just like all Linux distro kernels

However, given that the AF_BUS patches have been rejected by the
upstream Linux kernel developers, I advise that anyone relying on them
be very careful about their usage, and be prepared to move away from
them sometime in the future when this new "kernel dbus" code is properly

As for when this new kernel code will be finished, I can only respond
with the traditional "when it is done" mantra. I can't provide any
deadlines, and at this point in time, don't need any additional help
with it, we have enough people working on it at the moment. It's
available publicly if you really want to see it, but I'll not link to it
as it's nothing you really want to see or watch right now. When it
gets to a usable state, I'll announce it in the usual places
(linux-kernel mailing list) where it will be torn to the usual shreds
and I will rewrite it all again to get it into a mergable state.

In the meantime, if you see me at any of the many Linux conferences I'll
be attending around the world this year, and you are curious about the
current status, buy me a beer and I'll be glad to discuss it in person.

If there's anything else people are wondering about this topic, feel free
to comment on it here on google+, or email me.