BUS1 Still Remains Out Of The Mainline Linux Kernel, But DBus-Broker Continues

[Emmanuel Deloget]

As I said it is going to be another failure.

This is not a good thing. kdbus was some kind of a monster and did not belong to the kernel. But bus1 was better, and something should have been done to integrate it. We do need a kernel-supplied asynchronous message bus subsystem.

[ssokolow]

There are also other differences: http://kroah.com/log/blog/2014/01/15/kdbus-details/

I don't have a link handy, but I remember reading an LWN comment which elaborated on this snip:

and very easy to let fully untrusted peers take part of the communication model (hint, never let this happen with binder, or bad things will happen…)

IIRC, it said that Binder is only secure because of the combination of SELinux policy and Dalvik VM sandboxing that Android uses for all 3rd-party code.

[carewolf]

Couldn't Binder be used to accelerate communication between a D-BUS client and dbus-broker or the D-BUS daemon ?

Doubtful. You could use it in place of DBUS for certain things, but its design is too different to really interact well with D-BUS, you might as well use SHM then, which is the fastest IPC (but most barebone) and available everywhere but Android.

[nanonyme]

Just tried it out on fedora 28 beta. You still need the normal package to be installed, but if you enable dbus-broker service, it replaces the dbus.service.

https://github.com/bus1/dbus-broker/wiki

So far it works fine for me

Also as mentioned before, the intent is to go for dbus-broker by default in Fedora 29. I dunno if the package refactoring is yet done in Fedora 28 but it's probably easy to take into use manually

[cen1]

Can anyone explain me who would be the end user of BUS1? Is this like IPC mechanism?

[Venemo]

Can anyone explain me who would be the end user of BUS1? Is this like IPC mechanism?

Are you familiar with D-Bus? It is a mechanism for structured and asynchronous IPC (inter-process communication) that is in wide use today in Gnome and other desktops and apps. However there have been some performance bottlenecks so to make it all go faster, they implemented it as a kernel module instead, called kdbus. For some reason the kernel developers didn't like it and never accepted it upstream. So they made BUS1 which addressed most of the issues of kdbus, but could still be used with D-Bus.

I'm sad to see that kernel developers still hate it and refuse to merge it.

[oiaohm]

Are you familiar with D-Bus? It is a mechanism for structured and asynchronous IPC (inter-process communication) that is in wide use today in Gnome and other desktops and apps. However there have been some performance bottlenecks so to make it all go faster, they implemented it as a kernel module instead, called kdbus. For some reason the kernel developers didn't like it and never accepted it upstream. So they made BUS1 which addressed most of the issues of kdbus, but could still be used with D-Bus.

I'm sad to see that kernel developers still hate it and refuse to merge it.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=27eac47b00789522ba00501b0838026e1ecb6f05

The reason why dbus-broker need 4.14 or newer is the above feature. Running out of cpu due to bad kernel logic around AF_UNIX sockets is particularly bad.

Basically kdbus and bus1 caused a question what is wrong with AF_UNIX sockets. Turned out there were a lot of things wrong with the way AF_UNIX sockets was implemented that has been kicking the heck out of dbus daemon and resulting in it at times using 100 percent of the CPU and worse.

So a lot of ways with fixed AF_UNIX sockets and dbus-broker implementation needs to be deployed before another attempt at a kernel module. There were issues in the way dbus deamon was designed that came clear when kdbus attempted to copy dbus deamon logic straight into kernel space and it got peer reviewed this is why dbus-broker is required.

Both the kernel and userspace sides of dbus have been busted. Linux kernel 4.14 and newer sees the sockets side work.

So I kind of agree with Linus over rejecting both dbus1 and kdbus as there ware implementation errors in existing features in the Linux kernel that need fixing before doing more. Without fixing those kernel implementation errors with AF_UNIX it is impossible to benchmark if dbus1 solution works out faster than using existing kernel features from userspace. Also fixing up dbus-broker in userspace will allow rethinking about how dbus logic should operate and this may result in bus1 needing to be changed again.

[edoantonioco]

As I said it is going to be another failure.

But we need this to not be a failure.

[Venemo]

So I kind of agree with Linus over rejecting both dbus1 and kdbus as there ware implementation errors in existing features in the Linux kernel that need fixing before doing more. Without fixing those kernel implementation errors with AF_UNIX it is impossible to benchmark if dbus1 solution works out faster than using existing kernel features from userspace. Also fixing up dbus-broker in userspace will allow rethinking about how dbus logic should operate and this may result in bus1 needing to be changed again.

That is good to know, thanks!
Has anyone actually carried out any benchmark on whether or not the new AF_UNIX socket handling beats the BUS1 implementation?

[miabrahams]

That is good to know, thanks!
Has anyone actually carried out any benchmark on whether or not the new AF_UNIX socket handling beats the BUS1 implementation?

BUS1 hasn't progressed that far. It is plausible that dbus-broker could be modified to use BUS1 as a backend someday, but right now there is no implementation of dbus over BUS1.