4 ms·

>I've decided to take matters into my own hands. I am writing a new bus. Why not reuse Binder which has been to deployed to billions of devices, being a core p

>I've decided to take matters into my own hands. I am writing a new bus. Why not reuse Binder which has been to deployed to billions of devices, being a core part of a serious OS, with many many more developers who understand it compared to dbus. You would probably want to write your own service manager, but you can reuse hardened stuff that already exist.

zb3 11mo ago
Binder will come to linux desktop soon... together with Android :)
- anon-3988 11mo ago
  Is there any plans by some DE to replace D-bus with Binder?
bee_rider 11mo ago
Which OS? I didn’t get many results for BSD binder. Then I figured maybe you were joking about the “serious” part, so I tried windows binder, iOS binder, didn’t see much…
- schmichael 11mo ago
  https://source.android.com/docs/core/architecture/ipc/binder-overview https://source.android.com/docs/core/architecture/ipc/binder...
- charcircuit 11mo ago
  Binder is the primary way apps talk to the various OS services on Android. https://source.android.com/docs/core/architecture/ipc/binder-overview https://source.android.com/docs/core/architecture/ipc/binder... https://www.kernel.org/doc/html/latest/admin-guide/binderfs.html https://www.kernel.org/doc/html/latest/admin-guide/binderfs....
  - pjmlp 11mo ago
    Including drivers, as since Project Treble, starting with Android 8 all new drivers are required to be userspace, talking with the kernel via Android IPC (aka Binder). Traditional Linux drivers are considered legacy in Android.
    - charcircuit 11mo ago
      Well the userspace part of the driver. If they were only userspace they couldn't actually use the hardware. They have to have to be part of Linux or a kernel module to be able to talk to the hardware.
AshamedCaptain 11mo ago
There are few implementations of the Binder userspace outside of Android.
- pseudalopex 11mo ago
  How many implementations existed of their new bus?
  - AshamedCaptain 11mo ago
    Considering that any new implementation of Binder userspace would realistically also be incompatible with Android Binder, what would really be the gain here? You'd basically have yet another wire protocol that nobody else uses but now also depends on having a obscure Linux feature enabled.
    - kllrnohj 11mo ago
      Why would it need to be a new implementation? AOSP is like... right there, and it's not like libbinder has crazy dependencies. > also depends on having a obscure Linux feature enabled An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development. With the only real reason it's obscure on desktop linux at all is because upstream blocked it for a long time. If desktop linux embraced it, it certainly wouldn't be obscure anymore, now would it?
      - AshamedCaptain 11mo ago
        Most of binder is in outright Java. Libbinder_ndk is a subset that is unlikely to please anybody. The other libbinder (openbinder) is dead since 2006ish. I actually used this last one in certain commercial product. > An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development. Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, and also what D-Bus uses, there is just no contest. Even Android uses unix sockets more than Binder.
jabl 11mo ago
Yes! Make something built on top of binder, and use something with orders of magnitude more users and developer resources behind it.. > hardened stuff that already exist. To make it even more hardened(?), Google recently contributed and got merged a Rust implementation of binder for the Linux kernel (and they're apparently planning to eventually remove the old C implementation). https://lwn.net/Articles/953116/ https://lwn.net/Articles/953116/ https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-0-08ba9197f637@google.com/ https://lore.kernel.org/rust-for-linux/20231101-rust-binder-...
rendaw 11mo ago
Is Binder better than D-Bus? How so?
- charcircuit 11mo ago
  1. Better devex. The toolchain for binder properly checks that you are writing and reading transactions correctly and if you don't you get a compile time error. Meanwhile using dbus you can call things wrong and it will still compile. 2. Better latency. When you send a Binder transaction to another process Linux will immediately schedule the binder thread of the other process, unless it's a oneway transaction that does not block executon. Then once the other process replies, the original process is immediately rescheduled. Dbus does not affect Linux's scheduling of processes. When you send a dbus message any other process can be scheduled and run instead of the bus. And then anything can run in-between the bus sending the message to the target process. 3. Having the message go through the bus also results in extra copying. Not just cheap copying of memory. Since it's through a UNIX socket it has to use extra system calls to read out of and into another socket. As opposed to binder where it's able to simply copy the memory of the parcel from one process to another.
- uep 11mo ago
  My knowledge is outdated, as I last seriously looked at it about nine years ago, but I doubt Binder is even better than dbus; it was not good. I'm quite surprised with people suggesting it. There was that recent kernel Binder bug even with the rust implementation. It was rewritten in rust because it has had a never-ending string of serious security bugs. On top of that, it had very poor throughput. I'm guessing this improved with the rust implementation. It was a toy created by former OS devs who really didn't want to use Linux, but wanted their pet IPC from their former OS. It even used to be the case that Binder would dynamically create threads in the receiving process without userspace knowing. As in, your process would magically have function calls coming in from threads that you never created. Imagine the issues this can create with locking, forking, etc. This ended up being changed to get it upstreamed, but I consider this absolutely insane behavior.

zb3 11mo ago

Binder will come to linux desktop soon... together with Android :)

anon-3988 11mo ago
Is there any plans by some DE to replace D-bus with Binder?

bee_rider 11mo ago

Which OS? I didn’t get many results for BSD binder. Then I figured maybe you were joking about the “serious” part, so I tried windows binder, iOS binder, didn’t see much…

schmichael 11mo ago
https://source.android.com/docs/core/architecture/ipc/binder-overview https://source.android.com/docs/core/architecture/ipc/binder...
charcircuit 11mo ago
Binder is the primary way apps talk to the various OS services on Android. https://source.android.com/docs/core/architecture/ipc/binder-overview https://source.android.com/docs/core/architecture/ipc/binder... https://www.kernel.org/doc/html/latest/admin-guide/binderfs.html https://www.kernel.org/doc/html/latest/admin-guide/binderfs....
- pjmlp 11mo ago
  Including drivers, as since Project Treble, starting with Android 8 all new drivers are required to be userspace, talking with the kernel via Android IPC (aka Binder). Traditional Linux drivers are considered legacy in Android.
  - charcircuit 11mo ago
    Well the userspace part of the driver. If they were only userspace they couldn't actually use the hardware. They have to have to be part of Linux or a kernel module to be able to talk to the hardware.

AshamedCaptain 11mo ago

There are few implementations of the Binder userspace outside of Android.

pseudalopex 11mo ago
How many implementations existed of their new bus?
- AshamedCaptain 11mo ago
  Considering that any new implementation of Binder userspace would realistically also be incompatible with Android Binder, what would really be the gain here? You'd basically have yet another wire protocol that nobody else uses but now also depends on having a obscure Linux feature enabled.
  - kllrnohj 11mo ago
    Why would it need to be a new implementation? AOSP is like... right there, and it's not like libbinder has crazy dependencies. > also depends on having a obscure Linux feature enabled An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development. With the only real reason it's obscure on desktop linux at all is because upstream blocked it for a long time. If desktop linux embraced it, it certainly wouldn't be obscure anymore, now would it?
    - AshamedCaptain 11mo ago
      Most of binder is in outright Java. Libbinder_ndk is a subset that is unlikely to please anybody. The other libbinder (openbinder) is dead since 2006ish. I actually used this last one in certain commercial product. > An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development. Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, and also what D-Bus uses, there is just no contest. Even Android uses unix sockets more than Binder.

jabl 11mo ago

Yes! Make something built on top of binder, and use something with orders of magnitude more users and developer resources behind it.. > hardened stuff that already exist. To make it even more hardened(?), Google recently contributed and got merged a Rust implementation of binder for the Linux kernel (and they're apparently planning to eventually remove the old C implementation). https://lwn.net/Articles/953116/ https://lwn.net/Articles/953116/ https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-0-08ba9197f637@google.com/ https://lore.kernel.org/rust-for-linux/20231101-rust-binder-...

rendaw 11mo ago

Is Binder better than D-Bus? How so?

charcircuit 11mo ago
1. Better devex. The toolchain for binder properly checks that you are writing and reading transactions correctly and if you don't you get a compile time error. Meanwhile using dbus you can call things wrong and it will still compile. 2. Better latency. When you send a Binder transaction to another process Linux will immediately schedule the binder thread of the other process, unless it's a oneway transaction that does not block executon. Then once the other process replies, the original process is immediately rescheduled. Dbus does not affect Linux's scheduling of processes. When you send a dbus message any other process can be scheduled and run instead of the bus. And then anything can run in-between the bus sending the message to the target process. 3. Having the message go through the bus also results in extra copying. Not just cheap copying of memory. Since it's through a UNIX socket it has to use extra system calls to read out of and into another socket. As opposed to binder where it's able to simply copy the memory of the parcel from one process to another.
uep 11mo ago
My knowledge is outdated, as I last seriously looked at it about nine years ago, but I doubt Binder is even better than dbus; it was not good. I'm quite surprised with people suggesting it. There was that recent kernel Binder bug even with the rust implementation. It was rewritten in rust because it has had a never-ending string of serious security bugs. On top of that, it had very poor throughput. I'm guessing this improved with the rust implementation. It was a toy created by former OS devs who really didn't want to use Linux, but wanted their pet IPC from their former OS. It even used to be the case that Binder would dynamically create threads in the receiving process without userspace knowing. As in, your process would magically have function calls coming in from threads that you never created. Imagine the issues this can create with locking, forking, etc. This ended up being changed to get it upstreamed, but I consider this absolutely insane behavior.