Bringing D-Bus Into The Linux Kernel

[phoronix]

Phoronix: Bringing D-Bus Into The Linux Kernel

Alban Crequy, a Maemo developer, for the past several weeks have been working on bringing D-Bus directly into the Linux kernel. Why? Huge performance improvements...

http://www.phoronix.com/vr.php?view=ODYwNA

[sturmflut]

My interpretation of the numbers is different:

The speedup by a factor of two or three is only valid for a synthetic test case (ping-pong).

The benchmarks for real-world-cases show a speedup of 25 percent or less.

KDBus still needs a DBus daemon which handles a lot of stuff, the kernel-code is insecure and the speedup not that big. I would like to see how much can be improved by tuning the daemon alone before anybody starts putting user-space code into the kernel.

Kernel code complicates development a lot - it takes lots of time until changes are accepted and distributed to all users. One has to reboot. A daemon can be replaced anytime. I am not even sure Linus and his friends will accept these patches.

Finally, to say it in the words of another user: "d-bus is a horrible monster and cramming it into the kernel to save one second of jabber connectivity is one of the most brain-dead efforts I’ve seen in years."

[curaga]

Ewww. D-Bus itself is completely unnecessary, keep that thing out of the kernel.

[Shining Arcanine]

My interpretation of the numbers is different:

The speedup by a factor of two or three is only valid for a synthetic test case (ping-pong).

The benchmarks for real-world-cases show a speedup of 25 percent or less.

KDBus still needs a DBus daemon which handles a lot of stuff, the kernel-code is insecure and the speedup not that big. I would like to see how much can be improved by tuning the daemon alone before anybody starts putting user-space code into the kernel.

Kernel code complicates development a lot - it takes lots of time until changes are accepted and distributed to all users. One has to reboot. A daemon can be replaced anytime. I am not even sure Linus and his friends will accept these patches.

Finally, to say it in the words of another user: "d-bus is a horrible monster and cramming it into the kernel to save one second of jabber connectivity is one of the most brain-dead efforts I’ve seen in years."

It makes as much sense as it does to move X Windows into the kernel.

Ewww. D-Bus itself is completely unnecessary, keep that thing out of the kernel.

To be fair, it would be used only for userland processes. Kernel components would not use it for intra-kernel communication.

[Dubhthach]

It makes as much sense as it does to move X Windows into the kernel.

A commercial company already did that with a proprietary kernel module:
http://www.microxwin.com/

[brent]

I seriously doubt anyone is using D-Bus for performance-critical applications...

I don't agree though that it's unnecessary, a monster or anything. What's wrong with it? I've used it -- it's easy and works well.

[korpenkraxar]

I bet KDE would also be extremely snappy if moved into the kernel ;-)

[rohcQaH]

IMHO that's a horrible idea because that would freeze the API forever. Speed-improvements are somewhat minor, unless you start sending thousands of messages per second. Can anyone name a good use-case where you need both the flexibility of DBus and the speed of, say, a standard pipe?

As of now, DBus restricts messages to a single computer, making it unsuitable for an X environment where several apps may run on a different machine (see the new systray protocol).
In the long term, we would either need to route DBus through the X protocol or drop DBus for all uses where it's not suitable. The latter isn't going to happen; those that use DBus for such uses already decided not to care about remote X or multiple X sessions per user.

In other words, I'd like to see DBusRemote working before anything moves to the kernel.

[pingufunkybeat]

What the hell is the point, other than a small gain for Maemo devices?

Kill it! Kill it with fire!

[fabiank22]

I seriously doubt anyone is using D-Bus for performance-critical applications...

Uhhmm... KDE? I'm not sure, but I consider software I'm using on a daily basis "performance-critical". Sure, D-Bus is probably the least bottleneck KDE has, but performance improvement are always a good idea.

As for development/API, D-Bus has been more or less frozen thanks to the freedesktop spec they are following. Sure there are exceptions, but it's not like the kernel really has that much of a frozen API either, you can always be forward-compatible.