D-Bus 1.14 Released With Various Changes Built Up Over Four Years

[phoronix]

Phoronix: D-Bus 1.14 Released With Various Changes Built Up Over Four Years

It's been four years since the release of Dbus 1.12 (and even 20 months since the last point release [v1.12.20] up until this week when v1.12.22 was tagged) while today Dbus 1.14.0 is being introduced for this user-space IPC solution for Linux systems...

https://www.phoronix.com/scan.php?page=news_item&px=Dbus-1.14

[Mitch]

Is there a dramatic difference between the different IPC implementations from a user's perspective like resource usage, performance, latency, or energy usage/battery life?

[sarfarazahmad]

whatever happened to BUS1 (or whatever the in-kernel bus implementation that was going on) ?

[coder]

Is there a dramatic difference between the different IPC implementations from a user's perspective like resource usage, performance, latency, or energy usage/battery life?

You mean between the official DBus Daemon vs. DBus Broker? Or just between IPC mechanisms, in general?

The only DBus Broker benchmarks I've seen were pretty old, so I don't know how it compares, these days. An interesting benchmark for Michael to do would be to compare DBus Daemon vs. DBus Broker. However, I'm not aware of any existing ones that could be integrated into PTS. If anyone is interested, there are python bindings for dbus, which are very nice, but do have a bit of a learning curve.

As far as comparing different IPC frameworks, it helps to keep in mind their feature sets. The highest-performing ones likely don't support all the features of DBus, such as service-discovery and peer connection tracking. So, I'd say just be aware of what you're potentially giving up.

[coder]

whatever happened to BUS1 (or whatever the in-kernel bus implementation that was going on) ?

It got pulled and doesn't seem to have gotten much focus, of late. I think most of the effort going into optimizing DBus is in DBus Broker (userspace daemon).

On the client side, the most recent development is probably sdbus -- a part of libsystemd. I have a decent amount of experience with it, my biggest complaint being that the docs are rather sparse. In some cases, you need to look at their unit tests to see how a function is meant to be used. In other cases, I've actually resorted to reading their sources.

[sarfarazahmad]

Damn reading unit tests to understand how a function works, that's gotta be tough and time taking. Might as well document and put it up for other people to find. Maybe the documentation will come as the product matures.

[coder]

Damn reading unit tests to understand how a function works, that's gotta be tough and time taking. Might as well document and put it up for other people to find. Maybe the documentation will come as the product matures.

In fairness, the only times I had to do that were with peer connection-tracking and some case like appending an array of structures to a message. At the time, deadline pressure didn't permit me to write docs patches, but you raise a good point.

Another reason I find the business of submitting patches on API docs distasteful is that I'm of a rather strong opinion that no public API functions should exist without some basic level of documentation. Every class, enum, struct, function, parameter, and return value in my header files is always documented. Where appropriate, I put higher-level docs in the file header.

Having someone come back and write docs after the fact risks advertising an implementation bug or limitation that prevents the API from being extensible in some way, or otherwise becomes an obstacle. That's because a 3rd party cannot be certain about the original developer's intentions. And if it's years after the code was written, maybe the original developer has even forgotten some key details. One reason I document things is as notes to my future self. It has served me well.

Anyway, the sad reality is that the original developers of that library don't seem to regard documentation as a fundamental part of their work product. So, you're right. I should probably swallow my spite and contribute doc patches on anything there that's still undocumented.

[Mitch]

You mean between the official DBus Daemon vs. DBus Broker? Or just between IPC mechanisms, in general?

The only DBus Broker benchmarks I've seen were pretty old, so I don't know how it compares, these days. An interesting benchmark for Michael to do would be to compare DBus Daemon vs. DBus Broker. However, I'm not aware of any existing ones that could be integrated into PTS. If anyone is interested, there are python bindings for dbus, which are very nice, but do have a bit of a learning curve.

As far as comparing different IPC frameworks, it helps to keep in mind their feature sets. The highest-performing ones likely don't support all the features of DBus, such as service-discovery and peer connection tracking. So, I'd say just be aware of what you're potentially giving up.

I mean to say IPC mechanisms in general. It just makes me wonder if there's considerable performance or efficiency left on the table when we stick to some implementations over others. In my layman's understanding, IPC mechanisms sound critical, almost like the kernel itself.

[jacob]

Is there a dramatic difference between the different IPC implementations from a user's perspective like resource usage, performance, latency, or energy usage/battery life?

I don't have any benchmark data but Dbus Broker is supposed to offer much faster performance and better security than the default Dbus Daemon. But it achieves it by being Linux-specific while Dbus Daemon works on pretty much anything incl. BSD and Windows.

[jacob]

Anyway, the sad reality is that the original developers of that library don't seem to regard documentation as a fundamental part of their work product. So, you're right. I should probably swallow my spite and contribute doc patches on anything there that's still undocumented.

Although I agree that it's bad practice on their part, they probably consider sdbus as an internal helper more than a public API that 3rd party developers should be using. If you want to talk to systems, just use your language's normal Dbus bindings.