4 ms·

I wonder what happened to Bus1 [1] and other kdbus type proposals. Would be useful to have an android binder like ipc subsystem. 1. https://lwn.net/Articles/69

I wonder what happened to Bus1 [1] and other kdbus type proposals. Would be useful to have an android binder like ipc subsystem. 1. https://lwn.net/Articles/697191/ https://lwn.net/Articles/697191/ 2. https://lwn.net/Articles/580194/ https://lwn.net/Articles/580194/

p_l 2y ago
Binder is honestly much better than D-Bus, but for various reasons I don't think we're going to see it much on desktop (though you can, in fact, use it there - and it originates from exactly such use). The kdbus finally died when Linus sat down and proved that: 1) then-current userspace d-bus code was simply horrible which led to kdbus being mainly about speed/latency, but... 2) Linus spent a weekend and got an userspace dbus server 80/20 solution that achieved better performance than kdbus and 3) kdbus introduced no real new benefits that weren't ultimately triggered by "dbus is too slow", unlike Binder which involves fancy scheduling tricks to pass CPU quanta from one process to another along with RPC call. Thus the final nail in coffin of kdbus (which was previously hampered by being considered too problematic to merge) was hammered in.
- blucaz 2y ago
  kdbus/bus1 were about making IPC primitives available race-free to userspace since the very first moment it is started. Perf was icing on the cake. Binder is Google-only, so nobody else can really use it, given they might kill it at any moment. The end result of not having bus1 is that we have to forget about brokered IPC and go back to 1:1 bespoke protocols over af_unix - ie, varlink
  - p_l 2y ago
    Binder has been mainlined since a bit before kdbus project started, and can be in fact utilized with alternate implementations, as the kernel interface is explicitly not married to any specific content of the IPC.
wahern 2y ago
Linux did get memfd, which was originally a component of kdbus. kdbus seems to have failed because of arguments over attaching process capabilities to messages: https://lwn.net/Articles/641275/ https://lwn.net/Articles/641275/ And most if not all of the performance improvements were later realized with an improved user space D-Bus implementation (sd-bus?). bus1 seems to have followed a similar trajectory--what remains of the effort is a better D-Bus implementation in user space: https://github.com/bus1/dbus-broker https://github.com/bus1/dbus-broker
- mike_hearn 2y ago
  Linux lacks any equivalent of Apple's code signing and entitlements system, and as the kernel devs point out that leads to problems with making a proper kernel IPC system. The right fix would have been to do what Apple did and work out a namespaced and extensible system for capabilities/entitlements, but they never did it.

p_l 2y ago

Binder is honestly much better than D-Bus, but for various reasons I don't think we're going to see it much on desktop (though you can, in fact, use it there - and it originates from exactly such use). The kdbus finally died when Linus sat down and proved that: 1) then-current userspace d-bus code was simply horrible which led to kdbus being mainly about speed/latency, but... 2) Linus spent a weekend and got an userspace dbus server 80/20 solution that achieved better performance than kdbus and 3) kdbus introduced no real new benefits that weren't ultimately triggered by "dbus is too slow", unlike Binder which involves fancy scheduling tricks to pass CPU quanta from one process to another along with RPC call. Thus the final nail in coffin of kdbus (which was previously hampered by being considered too problematic to merge) was hammered in.

blucaz 2y ago
kdbus/bus1 were about making IPC primitives available race-free to userspace since the very first moment it is started. Perf was icing on the cake. Binder is Google-only, so nobody else can really use it, given they might kill it at any moment. The end result of not having bus1 is that we have to forget about brokered IPC and go back to 1:1 bespoke protocols over af_unix - ie, varlink
- p_l 2y ago
  Binder has been mainlined since a bit before kdbus project started, and can be in fact utilized with alternate implementations, as the kernel interface is explicitly not married to any specific content of the IPC.

wahern 2y ago

Linux did get memfd, which was originally a component of kdbus. kdbus seems to have failed because of arguments over attaching process capabilities to messages: https://lwn.net/Articles/641275/ https://lwn.net/Articles/641275/ And most if not all of the performance improvements were later realized with an improved user space D-Bus implementation (sd-bus?). bus1 seems to have followed a similar trajectory--what remains of the effort is a better D-Bus implementation in user space: https://github.com/bus1/dbus-broker https://github.com/bus1/dbus-broker

mike_hearn 2y ago
Linux lacks any equivalent of Apple's code signing and entitlements system, and as the kernel devs point out that leads to problems with making a proper kernel IPC system. The right fix would have been to do what Apple did and work out a namespaced and extensible system for capabilities/entitlements, but they never did it.