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."
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
What they won't tell you is that it's a proprietary module- shipping something with it to anyone other than in-house clients is a GPL violation against the Linux kernel itself.
Originally Posted by Dubhthach
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.
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.
Actually I'm only seeing a handful of messages per minute on the session bus (and almost none on the system bus), mostly kwin activations and kopete stuff.
Originally Posted by fabiank22
I'm surprised that dbus can actually become a bottleneck...
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.
Ewww. D-Bus itself is completely unnecessary, keep that thing out of the kernel.
Tags for this Thread