4 ms·

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

by AshamedCaptain 10mo ago

pseudalopex 10mo ago
How many implementations existed of their new bus?
- AshamedCaptain 10mo 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 10mo 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 10mo 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.
      - kllrnohj 10mo ago
        > Most of binder is in outright Java None of binder is in Java. The Java binder code is just JNI bindings to the native implementation. Things like permission manager are in Java, but that's not part of binder. It's just a service published on binder, and one that wouldn't translate to current desktop Linux anyway. > Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, and what both D-Bus, TFA's proposal, and literally any other reasonable desktop IPC proposal out there, there is just no contest. unix sockets are not an equivalent, which is why protocols are bolted on top to turn it into dbus, etc... EDIT: > The other libbinder (openbinder) is dead since 2006ish. The libbinder I meant is the one in AOSP hence why I said "AOSP is right there": https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/Android.bp;drc=79e7fcc2d771f6147ffa44dbef6985ac8101a320;l=570 https://cs.android.com/android/platform/superproject/main/+/... That one is very definitely not dead since 2006ish.
        AshamedCaptain 10mo ago
        "None of binder is in Java" is too strong a statement: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/os/Parcel.java https://android.googlesource.com/platform/frameworks/base/+/... This libbinder is still way too Java-centric. It can be used from outside, and even slightly reminds me of openbinder (e.g. sp<> https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/tests/binderRpcTest.cpp https://cs.android.com/android/platform/superproject/main/+/... ) but it doesn't really change the picture much. You have something which smells Java from a mile, and has a lot of other Android-isms to boot, so still likely requires to reinvent a lot of the wheel to actually use it for most desktop programs. Even the use of C++ is likely to frown many people. (Not me).
        charcircuit 10mo ago
        That is a java version of a class from libbinder. Having Java and native versions of classes is a common pattern for things meant to be used from both. https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/include/binder/Parcel.h https://cs.android.com/android/platform/superproject/main/+/...
  - nextaccountic 10mo ago
    Just use Android's implementation
    - ChocolateGod 10mo ago
      Isn't that tightly tied to the Android permission and app model, which is radically different from generic Linux.
      - nextaccountic 10mo ago
        Hopefully some distro will implement Android's permission on desktop then. Unix permissions were made for a time where we actually had multiple persons running software in the same OS (a use case that today is served by VMs) rather than protecting an app from another app run by the same user. https://xkcd.com/1200/ https://xkcd.com/1200/
aryonoco 10mo ago
Not widely known but the original Binder, OpenBinder, was not even for Linux or Android It was developed for BeOS. OpenBinder was one of the few pieces of code which was open sourced in Be Inc’s dying days just before it was acquired by Palm. Many of the principal Be developers who worked on OpenBinder, Dianne Hackborn, Jean-Baptiste Queru, et al then moved from Palm to Danger, which was developing Android and which was later acquired by Google. And the rest, as they say, is history.

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

pseudalopex 10mo ago

How many implementations existed of their new bus?

AshamedCaptain 10mo 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 10mo 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 10mo 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.
    - kllrnohj 10mo ago
      > Most of binder is in outright Java None of binder is in Java. The Java binder code is just JNI bindings to the native implementation. Things like permission manager are in Java, but that's not part of binder. It's just a service published on binder, and one that wouldn't translate to current desktop Linux anyway. > Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, and what both D-Bus, TFA's proposal, and literally any other reasonable desktop IPC proposal out there, there is just no contest. unix sockets are not an equivalent, which is why protocols are bolted on top to turn it into dbus, etc... EDIT: > The other libbinder (openbinder) is dead since 2006ish. The libbinder I meant is the one in AOSP hence why I said "AOSP is right there": https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/Android.bp;drc=79e7fcc2d771f6147ffa44dbef6985ac8101a320;l=570 https://cs.android.com/android/platform/superproject/main/+/... That one is very definitely not dead since 2006ish.
      - AshamedCaptain 10mo ago
        "None of binder is in Java" is too strong a statement: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/os/Parcel.java https://android.googlesource.com/platform/frameworks/base/+/... This libbinder is still way too Java-centric. It can be used from outside, and even slightly reminds me of openbinder (e.g. sp<> https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/tests/binderRpcTest.cpp https://cs.android.com/android/platform/superproject/main/+/... ) but it doesn't really change the picture much. You have something which smells Java from a mile, and has a lot of other Android-isms to boot, so still likely requires to reinvent a lot of the wheel to actually use it for most desktop programs. Even the use of C++ is likely to frown many people. (Not me).
        charcircuit 10mo ago
        That is a java version of a class from libbinder. Having Java and native versions of classes is a common pattern for things meant to be used from both. https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/include/binder/Parcel.h https://cs.android.com/android/platform/superproject/main/+/...
- nextaccountic 10mo ago
  Just use Android's implementation
  - ChocolateGod 10mo ago
    Isn't that tightly tied to the Android permission and app model, which is radically different from generic Linux.
    - nextaccountic 10mo ago
      Hopefully some distro will implement Android's permission on desktop then. Unix permissions were made for a time where we actually had multiple persons running software in the same OS (a use case that today is served by VMs) rather than protecting an app from another app run by the same user. https://xkcd.com/1200/ https://xkcd.com/1200/

aryonoco 10mo ago

Not widely known but the original Binder, OpenBinder, was not even for Linux or Android It was developed for BeOS. OpenBinder was one of the few pieces of code which was open sourced in Be Inc’s dying days just before it was acquired by Palm. Many of the principal Be developers who worked on OpenBinder, Dianne Hackborn, Jean-Baptiste Queru, et al then moved from Palm to Danger, which was developing Android and which was later acquired by Google. And the rest, as they say, is history.