If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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

Comment

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

Comment

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.

Comment

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.