AF_BUS, D-Bus, and the Linux kernel

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 this.

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 today.

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.

“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 work.

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 merged.

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
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
.