D-Bus Broker 18 Released While BUS1 In-Kernel IPC Remains Stalled

[phoronix]

Phoronix: D-Bus Broker 18 Released While BUS1 In-Kernel IPC Remains Stalled

Version 18 of D-Bus Broker has been released, the D-Bus message bus implementation designed for high performance and better reliability compared to the D-Bus reference implementation while sticking to compatibility with the original specification...

http://www.phoronix.com/scan.php?page=news_item&px=D-Bus-Broker-18

[foob444r]

Michael,

You are wrong in assuming efforts around BUS 1 have stalled.

It is still in the works, as validated by someone asking here: https://github.com/bus1/dbus-broker/...ment-444775507

shortly after which dvdhrm updated their local snapshot https://github.com/dvdhrm/bus1/commits/bus3

That commit replaced sender IDs with group tags to make breaking ties and improve total ordering gurantees, and not make it a mere artifact of the mechanism used.

[babali]

I wonder why every attempt at introducing kernel level DBUS's IPC failed. Did the BUS1 initiative give up?

[Murple]

Herr is an old but informative article on kdbus

https://lwn.net/Articles/641275/

[Guest]

Funny how for some of Linux's core systems we're basically at the mercy of one large company. If they see some problem as a pain point, it gets fixed, otherwise it gets stalled.

[LuukD]

@babali
Linus' concerns with BUS1 boiled down to security concerns. Linus argued that the design was vulnerable to DoS attacks because of the asynchronous nature of the message service (for performance you would not want the blocking type) plus the kernel service was made responsible for dealing with either problems of some application not accepting replies or a sender filing too many requests - if I understand and paraphrase correctly. That suggests Linus was not opposed to BUS1 IPC mechanism, rather was concerned with its workings. Note that this was in 2016 and I cannot find any more recent comments on the matter, nor can I find a second attempt to get it in(?)
[ https://marc.info/?l=linux-kernel&m=147751082518647&w=2 ]

[LuukD]

I'd love to see the dbus-broker more widely adopted, have more distributions embrace it or at-least offer it as a choice. dbus-broker means speeding up (threefold) all sorts of communication behind-the-scenes. If you have ever used Orca (tool using AT-SPI2; an accessibility protocol over D-Bus) you will have noticed a lot of actions yield a noticeable lag with dbus daemon. Now imagine you _depend_ on it. Shivers!
Either dbus is sped up (which is a full basket of fruit hanging low with dbus-broker available) - or alternatively whole ecosystems (clients, servers and protocol implementors) who at-least care somewhat about responsive behaviour and reliability over dbus has to convince every client and migrate to some other IPC method.

On a reddit thread on BUS1, someone argued that the push for faster dbus was pushed (or perhaps driven ) by automobile manufacturers and because they should not use dbus for those intents and purposes in the first place, BUS1 should not be included in the kernel.
Yes, interfaces are abused all the time, but that should not stop us from making those offerings faster, better, stronger. The car manufacturer who may or may not have picked the wrong IPC method will eventually find out. Wasting cycles while we can do much better to nudge some in a different direction is wasting our time and comfort too.

[cl333r]

Yeah, having a faster (and modern) D/Bus is good regardless of whether it's being misused by others.

[geearf]

Since it's provided by my distribution I just switched to using dbus-broker, not sure of the benefits yet but we'll see if it works fine at least.

[Farmer]

From what I remember one of the two main developers of "BUS1" was Kay Sievers. Given the collision between him and Torvalds over the systemd debug thing I wasn't surprised that BUS1 was being held to a rigid standard. Apparently they couldn't conform to it. Kroah-Hartman tired to place himself between the two groups for BUS1 but that apparently didn't last.

From memory. Wasn't involved - just remembering from ages later.