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?
Announcement
Collapse
No announcement yet.
Bringing D-Bus Into The Linux Kernel
Collapse
X
-
Originally posted by RealNC View PostBtw, 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?
D-Bus is a method of IPC, as for the advantages of using it:
Originally posted by WikipediaMessages 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.
Comment
-
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.
Comment
-
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.
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.
Comment
-
Originally posted by V!NCENT View PostIf 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.
[1] http://alban.apinc.org/blog/2010/09/...kernel-faster/
Comment
-
Read the comments to the original post.
Originally posted by phoronix View PostPhoronix: 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
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
-
Originally posted by liam View PostAlthough I like how clean dbus is, I wonder if we wouldn 't have been better with ORBit/CORBA (though it is massively more complicated)...
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
-
Originally posted by pingufunkybeat View PostI 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.
in short, dbus is nice and simple, as I've said, but Gnome needs more than it can provide, IMO.
Comment
-
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
-
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
Comment