D-Bus Broker 22 Released With Option To Use Newer Kernel Features

[phoronix]

Phoronix: D-Bus Broker 22 Released With Option To Use Newer Kernel Features

With BUS1 not looking like it will come to fruition anytime soon as an in-kernel IPC mechanism and the kernel module for it not being touched since last March, the same developers continue pushing ahead with Dbus-Broker as the user-space implementation focused on D-Bus compatibility while being higher performing and more reliable than D-Bus itself...

http://www.phoronix.com/scan.php?page=news_item&px=Dbus-Broker-22-Released

[halo9en]

I installed dbus-broker months ago and completely forgot about it. Pretty stable, no issues.

[tildearrow]

Typo:

This Dbus-broker bpdate also has fixes for Musl libc support.

[ermo]

One has to wonder if BUS1 is even needed if the most critical and speed-sensitive issues can be now instead be solved by a (set of) eBPF program(s)?

[jacob]

One has to wonder if BUS1 is even needed if the most critical and speed-sensitive issues can be now instead be solved by a (set of) eBPF program(s)?

Wouldn't a purely userspace implementation, Dbus-Broker included, suffer from priority inversion problems?

[R41N3R]

I installed dbus-broker months ago and completely forgot about it. Pretty stable, no issues.

Me too, I did it even on several different systems. I expected at least some issues, but couldn't find any so far :-)

[Britoid]

One has to wonder if BUS1 is even needed if the most critical and speed-sensitive issues can be now instead be solved by a (set of) eBPF program(s)?

I think in-kernel BUS1 would be handy because it would make DBUS available super early in the boot process.

[oiaohm]

One has to wonder if BUS1 is even needed if the most critical and speed-sensitive issues can be now instead be solved by a (set of) eBPF program(s)?

eBPF is not without is fair share of issues.

I think in-kernel BUS1 would be handy because it would make DBUS available super early in the boot process.

This is on the right track. Even a ebpf version could be started really early from the initramfs so this is not the full story.

eBPF is not a free lunch you have to spend building eBPF every start up of dbus. eBPF makes sense for items that are configurable large section of BUS1 stuff would be static code with no configuration so would make more sense as a build once solution. So a mix of eBPF and static code would make sense for implementing dbus in kernel space. eBPF like for permission rules.

Wouldn't a purely userspace implementation, Dbus-Broker included, suffer from priority inversion problems?

The answer is a horrible no. Kernel space or userspace is the kernel scheduler that deals with priority inversion issues. Dbus-broker does not attempt to be a pure userspace solution this is why is not as cross platform as dbus daemon.

Current dbus-broker is not pure userspace it need particular syscalls that are in Linux kernel 4.17 or newer so the kernel scheduler knows what the heck is going on.

Yes one of the arguments for kdbus was priority inversion and the Linux kernel developers were like no you don't need kernel space for that instead you should be using following syscalls to give the right information to kernel to deal with that for you.

[ermo]

Wouldn't a purely userspace implementation, Dbus-Broker included, suffer from priority inversion problems?

You tell me?

[indepe]

Yes one of the arguments for kdbus was priority inversion and the Linux kernel developers were like no you don't need kernel space for that instead you should be using following syscalls to give the right information to kernel to deal with that for you.

And also there are additional ways of avoiding priority inversion, for example asynchronous processing, that apply to userspace just as well. (Low priority threads blocking mixed priority mutexes is not a great thing in the first place.)