Originally posted by Azrael5
View Post
Announcement
Collapse
No announcement yet.
BUS1 Still Remains Out Of The Mainline Linux Kernel, But DBus-Broker Continues
Collapse
X
-
Originally posted by pininety View Post
There are also other differences: http://kroah.com/log/blog/2014/01/15/kdbus-details/
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…)
- Likes 6
Comment
-
Originally posted by wagaf View Post
Couldn't Binder be used to accelerate communication between a D-BUS client and dbus-broker or the D-BUS daemon ?
- Likes 1
Comment
-
Originally posted by treba View Post
- Likes 1
Comment
-
Originally posted by cen1 View PostCan anyone explain me who would be the end user of BUS1? Is this like IPC mechanism?
I'm sad to see that kernel developers still hate it and refuse to merge it.
Comment
-
Originally posted by Venemo View PostAre 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.
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.
- Likes 9
Comment
-
Originally posted by oiaohm View PostSo 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.
Has anyone actually carried out any benchmark on whether or not the new AF_UNIX socket handling beats the BUS1 implementation?
Comment
-
Originally posted by Venemo View PostThat 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?
Comment
Comment