Page 1 of 6 123 ... LastLast
Results 1 to 10 of 53

Thread: Bringing D-Bus Into The Linux Kernel

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,182

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

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

  2. #2
    Join Date
    Oct 2009
    Posts
    60

    Default

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

  3. #3

    Default

    Quote Originally Posted by sturmflut View Post
    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.

    Quote Originally Posted by curaga View Post
    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.

  4. #4
    Join Date
    Feb 2009
    Posts
    19

    Default

    Quote Originally Posted by Shining Arcanine View Post
    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/

  5. #5
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by Dubhthach View Post
    A commercial company already did that with a proprietary kernel module:
    http://www.microxwin.com/
    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.

  6. #6
    Join Date
    Jan 2010
    Posts
    365

    Default

    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.

  7. #7
    Join Date
    Jul 2009
    Posts
    47

    Default

    Quote Originally Posted by brent View Post
    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.

  8. #8
    Join Date
    Jan 2009
    Location
    Italy
    Posts
    82

    Default

    Quote Originally Posted by fabiank22 View Post
    Uhhmm... KDE?
    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.
    I'm surprised that dbus can actually become a bottleneck...

  9. #9
    Join Date
    Nov 2008
    Posts
    776

    Default

    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.

  10. #10
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,195

    Default

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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •