KDBUS Submitted For Review To The Mainline Linux Kernel

[phoronix]

Phoronix: KDBUS Submitted For Review To The Mainline Linux Kernel

It looks like KDBUS, the Linux kernel D-Bus implementation, is posed to be added to the next kernel release after Greg Kroah-Hartman sent out its patches today...

http://www.phoronix.com/vr.php?view=MTgyNTQ

[valeriodean]

And... BOOOM! The dance is started! :-)

[uid313]

Is D-Bus even good?
I mean D-Bus is a Linux-only, and there are other alternatives which maybe should be considered that perhaps is better?

What about JSON, Protocol Buffers, or Thrift?

[ssokolow]

Is D-Bus even good?
I mean D-Bus is a Linux-only, and there are other alternatives which maybe should be considered that perhaps is better?

What about JSON, Protocol Buffers, or Thrift?

I don't have the URLs handy, but it has been explained, in detail, why all of those options are unsuitable... both here and on LWN, either directly or as links to blog posts.

From what I remember, it boils down to:
1. KDBus is lower level than the API exposed by the D-Bus client libraries, so it's more about semantics than syntax
2. D-Bus is an introspectable RPC system and JSON is just a data interchange format... but you can always pass JSON as data in a D-Bus call.
3. JSON-RPC offers no advantages and various downsides.
4. Protocol Buffers have different semantics and there's no benefit to be had from shoehorning them and D-Bus together.
5. It's been too long. I don't remember what the argument against Thrift was.

(That's also why Android's Binder isn't an option. D-Bus is an asynchronous, memory-bound RPC API with a desktop-safe security model. Binder is a synchronous, CPU-bound RPC API with a security model that renders it unsafe for use on any desktop system.)

[NotMine999]

Another kernel Option To "untick"

Phoronix: KDBUS Submitted For Review To The Mainline Linux Kernel

It looks like KDBUS, the Linux kernel D-Bus implementation, is posed to be added to the next kernel release after Greg Kroah-Hartman sent out its patches today...

http://www.phoronix.com/vr.php?view=MTgyNTQ

I never found any value in DBUS. All DBUS ever seemed to do for my systems was "burn" CPU cycles and slow down the overall responsiveness of the system. I never saw any measurable differences in application performance with DBUS.

I guess DBUS was meant for desktop environments, but I run servers, so "desktop oriented" stuff just isn't needed and the added "bloat" is not necessary.

Now we have this. Fine. Another kernel option to "untick" when I "roll my own"....

[Ancurio]

I never found any value in DBUS. All DBUS ever seemed to do for my systems was "burn" CPU cycles and slow down the overall responsiveness of the system. I never saw any measurable differences in application performance with DBUS.

I guess DBUS was meant for desktop environments, but I run servers, so "desktop oriented" stuff just isn't needed and the added "bloat" is not necessary.

Now we have this. Fine. Another kernel option to "untick" when I "roll my own"....

Do you also build your kernels without netlink support?

[Delgarde]

I don't have the URLs handy, but it has been explained, in detail, why all of those options are unsuitable... both here and on LWN, either directly or as links to blog posts.

From what I remember, it boils down to:
...

But above all, the main reason is that none of those things are DBUS. Because that was the objective, right... not just to provide an in-kernel IPC service, but to provide one that could replace the existing DBUS user-space daemon without having to rewrite all the existing client code. None of those things would have served the design goals of KDBUS...

[justmy2cents]

Is D-Bus even good?
I mean D-Bus is a Linux-only, and there are other alternatives which maybe should be considered that perhaps is better?

What about JSON, Protocol Buffers, or Thrift?

dbus works everywhere. there's even windows version. as far as if it is good... i'm yet to see one IPC that is as friendly to work with and has as many features. at least that was my opinion.

as for named options, you should check what dbus is and compare to what you suggested

[pal666]

Another kernel option to "untick" when I "roll my own"....

sane people do not roll their own

[mark45]

I never found any value in DBUS. All DBUS ever seemed to do for my systems was "burn" CPU cycles and slow down the overall responsiveness of the system. I never saw any measurable differences in application performance with DBUS.

I guess DBUS was meant for desktop environments, but I run servers, so "desktop oriented" stuff just isn't needed and the added "bloat" is not necessary.

Now we have this. Fine. Another kernel option to "untick" when I "roll my own"....

And that's why KDBUS is going to replace dbus.
For the angry assholes who prefer to hate before bothering to learn here's a full video.

Among other things, classic DBUS does:
- 10 message/data copies, 4 validations, 4 context switches,
KDBUS does:
- 2 or less copies (up to zero-copy), 2 validations, 2 context switches

And other big-time improvements, also, it's meant as a powerful IPC, not as a unix socket replacement. And like systemd - it's easy to hate it and panick until you actually bother learning about it.