D-Bus Implementation Aiming For The Linux Kernel

[HyperDrive]

it is. that's exaclty the reason why the initiator of this wants it to move to kernel space.

he has actually running an own kernel version running in the automotive industry exactly because of this. dbus as daemon might not be too slow for desktop systems but it is when it comes to embeded or low power devices.

and it might also affect scientific calculations in some special cases.

p.s. would helpo a lot if people would read more than the headline. a slightly deeper look at the background could answer a lot of questions and solve a lot of misassumptions.

If I remember correctly, D-Bus was (still is?) about 17 times *slower* than ORBit (CORBA), so it needs all the help it can get...

[highlandsun]

If I remember correctly, D-Bus was (still is?) about 17 times *slower* than ORBit (CORBA), so it needs all the help it can get...

Agreed, it's a POS. But if you profile a typical DBUS transaction you'll see that a ton of time is sucked up in the userland libraries, not just in the daemon itself. Developing a new message transport in the kernel isn't going to magically improve the overall performance, the libraries still suck.

[liam]

If I remember correctly, D-Bus was (still is?) about 17 times *slower* than ORBit (CORBA), so it needs all the help it can get...

Have a link for that?
http://blogs.gnome.org/abustany/2010...of-the-report/
That paper examines the performance of various ipc methods for a specific transaction (querying a sqlite db). The methods tested were dbus, dbus with fd passing (what he calls the hybrid approach), a custom ipc socket based approach, and direct sqlite access. As expected direct access was fastest but only by about 20% over dbus with fd and the custom unix socket. So, that doesn't seem too bad.

[HyperDrive]

Have a link for that?

Sure, here it is: http://eleceng.dit.ie/frank/rpc/CORB...ceAnalysis.pdf.
Seems rather outdated, though (tests were done on Slackware 10.2, released in 2005), so D-Bus had a lot of time to improve since then.

http://blogs.gnome.org/abustany/2010...of-the-report/
That paper examines the performance of various ipc methods for a specific transaction (querying a sqlite db). The methods tested were dbus, dbus with fd passing (what he calls the hybrid approach), a custom ipc socket based approach, and direct sqlite access. As expected direct access was fastest but only by about 20% over dbus with fd and the custom unix socket. So, that doesn't seem too bad.

I got quite fast, indeed! File descriptor passing was implemented in 2009 by Lennart Poettering, so that paper I read is obsolete, thankfully.

[liam]

Sure, here it is: http://eleceng.dit.ie/frank/rpc/CORB...ceAnalysis.pdf.
Seems rather outdated, though (tests were done on Slackware 10.2, released in 2005), so D-Bus had a lot of time to improve since then.
I got quite fast, indeed! File descriptor passing was implemented in 2009 by Lennart Poettering, so that paper I read is obsolete, thankfully.

Glad you liked that
Thanks for the link, but, as you say, a lot has changed since then.
Honestly I don't know why dbus gets the bad rap. Sure, I wish the commandline tool handled some sort of introspection so I could more easily examine the messages, but this can be done, in principle, and, more importantly, it provides well defined interfaces and is pretty performant.

[curaga]

Glad you liked that
Thanks for the link, but, as you say, a lot has changed since then.
Honestly I don't know why dbus gets the bad rap. Sure, I wish the commandline tool handled some sort of introspection so I could more easily examine the messages, but this can be done, in principle, and, more importantly, it provides well defined interfaces and is pretty performant.

It's a NIH IPC mechanism that has many downsides (weird protocol, requires a daemon) while most of its users do not make use of its strengths (multicast simpler than via networking).

It's existence has so led many apps that do not need it to use it, just because it's the official fd.o alternative. Which brings the downside of having to run the unnecessary daemon to users.


It's security and other issues like performance do not concern me; its primary downside to me is the requirement on a daemon. I'm sure others have other reasons to dislike it.

[curaga]

I fail twice with its vs it's, good indication that it's a morning

[Ericg]

It's a NIH IPC mechanism

Of course its NIH, Gnome and KDE didnt collaborate at all back then so you had KDE with D-Cop which eventually became D-bus, and you had Gnome with ORBit. KDE's solution won out as far as community support

[TheBlackCat]

Of course its NIH, Gnome and KDE didnt collaborate at all back then so you had KDE with D-Cop which eventually became D-bus, and you had Gnome with ORBit. KDE's solution won out as far as community support

I don't think that is an entirely accurate summary. KDE developed dcop. Rather than adopting KDE's existing technology, Gnome created an incompatible clone of it, then had it declared an fd.o standard. So KDE, trying to be cooperative, abandoned dcop and adopted dbus (dbus at the time was technologically inferior). This seems to be how many fd.o standards come about.

And I am not sure what you mean by "back then", Gnome still doesn't collaborate beyond telling everyone else to do things their way.

[Ericg]

I don't think that is an entirely accurate summary. KDE developed dcop. Rather than adopting KDE's existing technology, Gnome created an incompatible clone of it, then had it declared an fd.o standard. So KDE, trying to be cooperative, abandoned dcop and adopted dbus (dbus at the time was technologically inferior). This seems to be how many fd.o standards come about.

And I am not sure what you mean by "back then", Gnome still doesn't collaborate beyond telling everyone else to do things their way.

Dbus FAQ:

10.

How does D-Bus differ from CORBA?

Start by reading Q: 9.

CORBA is designed to support object-oriented IPC between objects, automatically marshalling parameters as necessary. CORBA is strongly supported by the Open Management Group (OMG), which produces various standards and supporting documents for CORBA and has the backing of many large organizations. There are many CORBA ORBs available, both proprietary ORBs and free / open source software ORBs (the latter include ORBit, MICO, and The ACE Orb (TAO)). Many organizations continue to use CORBA ORBs for various kinds of IPC.

Both GNOME and KDE have used CORBA and then moved away from it. KDE had more success with a system called DCOP, and GNOME layered a system called Bonobo on top of CORBA. Without custom extensions, CORBA does not support many of the things one wants to do in a desktop environment with the GNOME/KDE architecture.

CORBA on the other hand has a number of features of interest for enterprise and web application development, though XML systems such as SOAP are the latest fad.

Like D-Bus, CORBA uses a fast binary protocol (IIOP). Both systems work in terms of objects and methods, and have concepts such as "oneway" calls. Only D-Bus has direct support for "signals" as in GLib/Qt (or Java listeners, or C# delegates).

D-Bus hardcodes and specifies a lot of things that CORBA leaves open-ended, because CORBA is more generic and D-Bus has two specific use-cases in mind. This makes D-Bus a bit simpler.

However, unlike CORBA D-Bus does not specify the API for the language bindings. Instead, "native" bindings adapted specifically to the conventions of a framework such as QObject, GObject, C#, Java, Python, etc. are encouraged. The libdbus reference implementation is designed to be a backend for bindings of this nature, rather than to be used directly. The rationale is that an IPC system API should not "leak" all over a program; it should come into play only just before data goes over the wire. As an aside, OMG is apparently working on a simpler C++ binding for CORBA.

Many CORBA implementations such as ORBit are faster than the libdbus reference implementation. One reason is that D-Bus considers data from the other end of the connection to be untrusted and extensively validates it. But generally speaking other priorities were placed ahead of raw speed in the libdbus implementation. A fast D-Bus implementation along the lines of ORBit should be possible, of course.

On a more trivial note, D-Bus involves substantially fewer acronyms than CORBA.

16.

How does D-Bus differ from DCOP?

Start by reading Q: 9.

D-Bus is intentionally pretty similar to DCOP, and can be thought of as a "DCOP the next generation" suitable for sharing between the various open source desktop projects.

D-Bus is a bit more complex than DCOP, though the Qt binding for D-Bus should not be more complex for programmers. The additional complexity of D-Bus arises from its separation of object references vs. bus names vs. interfaces as distinct concepts, and its support for one-to-one connections in addition to connections over the bus. The libdbus reference implementation has a lot of API to support multiple bindings and main loops, and performs data validation and out-of-memory handling in order to support secure applications such as the systemwide bus.

D-Bus is probably somewhat slower than DCOP due to data validation and more "layers" in the reference implementation. A comparison hasn't been posted to the list though.

At this time, KDE has not committed to using D-Bus, but there have been discussions of KDE bridging D-Bus and DCOP, or even changing DCOP's implementation to use D-Bus internally (so that GNOME and KDE would end up using exactly the same bus). See the KDE mailing list archives for some of these discussions.

Sounds like dbus is more dcop than bonobo/ORBIT/Cobra