Bringing D-Bus Into The Linux Kernel

[RealNC]

Btw, what is wrong with IPC, which is already in the kernel? (At least I think it is.) I don't know much about the topic and wonder if there's something D-Bus does that IPC can't?

[fabiank22]

Btw, what is wrong with IPC, which is already in the kernel? (At least I think it is.) I don't know much about the topic and wonder if there's something D-Bus does that IPC can't?

I assume you're talking about Inter Process-Communication, and yes, that's been part of POSIX since forever. However you're mistaking methods and implementations.

D-Bus is a method of IPC, as for the advantages of using it:

Messages received over a D-Bus connection get routed to a specific object, not to the application as a whole. In this way, D-Bus resembles software componentry, as it appears to users as if they are interacting with an object across the IPC connection, whether or not there is an object on the other side.

[V!NCENT]

You guys seem to miss the point because almost everything these days uses dbus. So it is not _just_ Firefox or _just_ Jabber.

If what PinguFunkyBeat says is true, that dbus is unoptimized, then I do think that they should do some work there before taking it to the kernel.

[fabiank22]

Damn Edit Limit.

Anyway from the D-Bus faq:

How does D-Bus differ from other interprocess communication or networking protocols?


Keep in mind, it is not only an IPC system; it also includes lifecycle tracking, service activation, security policy, and other higher-level structure and assumptions.

And:

D-Bus communication with the intermediate bus daemon should be (and as last profiled, was) about twice as slow as one-to-one mode, because a round trip involves four socket reads/writes rather than two socket reads/writes.

The overhead comes from a couple of places; part of it is simply "abstraction penalty" (there are layers of code to support multiple main loops, multiple transport types, security, etc.). Probably the largest part comes from data validation (because the reference implementation does not trust incoming data). It would be simple to add a "no validation" mode, but probably not a good idea all things considered.

Raw bandwidth isn't the only concern; D-Bus is designed to enable asynchronous communication and avoid round trips. This is frequently a more important performance issue than throughput.

[tettamanti]

If what PinguFunkyBeat says is true, that dbus is unoptimized, then I do think that they should do some work there before taking it to the kernel.

From what I gather from [1] dbus not only validates, but also partially rewrites the messages as they pass through. In a RO scenario (which includes validation) it would be possible to use tee and splice to avoid the copy (but not the CS).

[1] http://alban.apinc.org/blog/2010/09/...kernel-faster/

[liam]

Read the comments to the original 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

[pingufunkybeat]

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.

[liam]

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.

[highlandsun]

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

[phtpht]

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.