Announcement

Collapse
No announcement yet.

Bringing D-Bus Into The Linux Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Read the comments to the original post.

    Originally posted by phoronix View Post
    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
    This isn't going into the kernel as it is now.
    DBus IS a bottleneck when processes are being overly verbose. The coolest idea I saw in the comments was of using the linux virtual networking facilities to model dbus, and then you have the security bonus in using an iptables-like setup, as well as QoS so you can expedite high priority messages. Cool.
    Someone also made the excellent point about the using xml as the dbus language. Although messages, on average, are pretty short, something a wee bit more terse would seem to be in order, especially with many processes vying for access to the daemon.
    Although I like how clean dbus is, I wonder if we wouldn 't have been better with ORBit/CORBA (though it is massively more complicated)...

    Best/Liam

    Comment


    • #47
      Originally posted by liam View Post
      Although I like how clean dbus is, I wonder if we wouldn 't have been better with ORBit/CORBA (though it is massively more complicated)...
      I doubt it.

      Everyone said that CORBA would suck for this role, and GNOME did it anyway. After many years of attempting to get it working (while DCOP/KParts worked and was used universally in KDE, at a fraction of the effort), they gave up and switched to dbus, which is very similar to dcop in both principles and implementation.

      Comment


      • #48
        Originally posted by pingufunkybeat View Post
        I doubt it.

        Everyone said that CORBA would suck for this role, and GNOME did it anyway. After many years of attempting to get it working (while DCOP/KParts worked and was used universally in KDE, at a fraction of the effort), they gave up and switched to dbus, which is very similar to dcop in both principles and implementation.
        Certainily dbus worked, but it didn't do everything CORBA did. For one thing, CORBA was designed to handle distributed systems (something that will be increasingly useful - consider the recent issues the telepathy people have had extending their tubes with dbus). CORBA was able to handle components (something that I believe qt has built in, but that gtk+ hasn't). With the adoption of dbus Gnome has lost this ability. The big problem with CORBA was the lack of sugar bindings. I know the Novell people were able to work with it, but we still needed good documention for ORBit.
        in short, dbus is nice and simple, as I've said, but Gnome needs more than it can provide, IMO.

        Comment


        • #49
          Profile the code. DBus is still a pig. The header pasting and other stuff is utterly braindead, there are too many copy operations to forward a message thru the code. The fact that a roundtrip takes 4 system calls is bad enough relative to simple localhost multicast, but that's still not much overhead in the kernel. It's the other header munging crap that DBus does that makes it such a pig, and tossing that into the kernel won't make it suck any less.

          The design was pretty stupid to begin with, all of these long strings for application/port addresses are inane. You already have to contact a central broker to establish your source and destination addresses; they should have used the central broker to map these string-form addresses into compact numeric ports (gee, like DNS and IP addresses, what a *novel* idea...) and only used the compact addresses in the actual message traffic. Only a moron would design a purely string-based addressing scheme for a communication protocol. In most DBus apps the string handles are larger than the actual application message data.

          Idiots...

          Comment


          • #50
            Oh yeah. Let's move everything into the kernel. Of course it *will* be faster when it requires no context switches. And you know what, it will be even faster if we ditch memory paging, pmode, etc and just use DOS. When will these people learn?

            What happened to the "kernel is the small stable and secure thing that has sole access to the hardware"? If we put every other service into the kernel just because of performance it will become soon zero day heaven. The "context switch" thingy has a purpose and its delay is a price the wise guys of the past have decided is well worth its benefits.

            Comment


            • #51
              Originally posted by highlandsun View Post
              there are too many copy operations to forward a message thru the code
              And what the heck is wrong with memory copying? The memory is already order of magnitude faster than the rest of the system. Is d-bus the interface that you would stream movies through or what? Normally d-bus is used for messages like "you have new mail".

              Comment


              • #52
                If you claim to be concerned with performance but you're not concerned with memory usage or copies, you're an idiot. Memory may be "orders of magnitude faster than the rest of the system" but it's still orders of magnitude slower than the CPU.

                Comment


                • #53
                  Originally posted by highlandsun View Post
                  If you claim to be concerned with performance but you're not concerned with memory usage or copies, you're an idiot. Memory may be "orders of magnitude faster than the rest of the system" but it's still orders of magnitude slower than the CPU.
                  I'm not sure if this was wrt my post but the point is I am not concerned. No sane person should give a damn if the "you've got mail" message ... which is how big? 100 bytes with a big reserve... is present one or five times in the memory, if it is backed by registers or cache or RAM, and absolutely not if advancing in this area means losing all memory/process protection that is in the OS.

                  Comment

                  Working...
                  X