Bringing D-Bus Into The Linux Kernel
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...
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."
Ewww. D-Bus itself is completely unnecessary, keep that thing out of the kernel.
It makes as much sense as it does to move X Windows into the kernel.
Originally Posted by sturmflut
To be fair, it would be used only for userland processes. Kernel components would not use it for intra-kernel communication.
Originally Posted by curaga
A commercial company already did that with a proprietary kernel module:
Originally Posted by Shining Arcanine
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.
I bet KDE would also be extremely snappy if moved into the kernel ;-)
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.
What the hell is the point, other than a small gain for Maemo devices?
Kill it! Kill it with fire!
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.
Originally Posted by brent
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.
Tags for this Thread