Here is a very good article about BUS1, which also compares it with binder. It also explains that BUS1 only implements the very basic elements for a multicast IPC inside the kernel space, but needs some user space elements to be really useful. This is the fact that, IMHO, could help to make it merged in the kernel source.
Announcement
Collapse
No announcement yet.
BUS1, The Successor To KDBUS, Formally Unveiled -- Aiming For Mainline Linux Kernel
Collapse
X
-
Originally posted by 89c51 View Post
Could someone explain how wayland is involved with bus1? Does he mean rewrite of wayland to look more like bys1?
- Likes 1
Comment
-
Originally posted by yoshi314 View Postthe problem was that it did not solve the problem it was supposed to solve (performance), and was completely insecure. it was far from perfect replacement.
Originally posted by yoshi314 View Posti think that coupling bus1 with some userspace compatibility wrapper that would act as a drop in replacement for dbus would also serve as a perfect replacement. assuming that bus1 is well designed and passes the review.
- Likes 2
Comment
-
Why should binder exist? What about making a common solution instead bloating the kerne with more subsystems from different Linux-based pseudo-propietary distributions?
This is worse than forking! It's a f$$$g mess!
Originally posted by https://kernelnewbies.org/Linux_3.19#head-fa49268d45ce9bae2e47c5a75ef0333947fa18a61.4. Android binder moved to stable
The Android binder code has been placed in the "staging" are of the kernel for a long time. The code, however, has been stable for many years now and it has been shipped in millions of phones. There has been reticences over binder, but no matter what comes in the future, Linux is going to have to support this API anyway, so might as well move it to the "real" part of the kernel.
Code: commit
Comment
-
Originally posted by timofonic View Post
What are you talking about? (Open)Binder (it comes from Be, Inc famous of BeOS, then Palm Inc. bought Be, Inc.) has been part of Linux kernel since years and became stable in February 2015.
Why should binder exist? What about making a common solution instead bloating the kerne with more subsystems from different Linux-based pseudo-propietary distributions?
This is worse than forking! It's a f$$$g mess!
Comment
-
Originally posted by carewolf View Post
Because binder doesn't do any of the things bus1 does, and which it is intended for. Primarily multicast, the fact that underlying mechanics operate similar to the uni-cast binder would a point in its favor. Also that it avoid the terrible design choices of binder like global locks is another.
So why about Android ditching Binder and use DBUS1 instead?
Comment
-
Originally posted by timofonic View Post
So why about Android ditching Binder and use DBUS1 instead?
Comment
-
Originally posted by ssokolow View Post
They wouldn't "ditch" Binder because too much 3rd-party userland code depends on those APIs... but they might scrape out its guts and replace them with BUS1, similar to how kdbus would have presented the libdbus APIs but been a different beast under the hood.
Comment
-
Originally posted by timofonic View Post
What kind of userland code? Isn't Android based on Java framework and their own API? Do they expose Binder to userland? :O
(By call semantics, I mean details like blocking vs. non-blocking, what level of ordering constraints between calls (none, same process, same sender to all processes, etc.) are guaranteed, etc.)
Comment
Comment