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.
> 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://lore.kernel.org/rust-for-linux/20231101-rust-binder-...
> 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?
> 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.
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/+/...
That one is very definitely not dead since 2006ish.
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/+/... ) 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).
https://cs.android.com/android/platform/superproject/main/+/...
No, of course not, that'd be absurd. Same thing with Parcel & Binder. Java bindings existing does not change the simple fact that binder itself does not have any Java in it. It's regularly used in processes with zero Java at all, this isn't a hypothetical it's a basic reality. That's why binder is used for HALs and similar low-level systems.
it does if the only other implementation is basically the JNI native methods of dbus-java. This is what libbinder_ndk looks like from the outside. If there's a newer libbinder that does not look like a Java mess , I have not yet seen it.
Not negating that it may exist; the libbinder you quoted above looks similar to openbinder but I have never used it.
[1] BeOS, the docs still match what is in Android :D
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.
https://source.android.com/docs/core/architecture/ipc/binder...
https://www.kernel.org/doc/html/latest/admin-guide/binderfs....
Traditional Linux drivers are considered legacy in Android.
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.
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.