3 ms·

It’s unfortunate that dbus is used instead of a kernel-level IPC mechanism; despite how difficult it is to work with directly, Mach IPC is one of the hidden gem

It’s unfortunate that dbus is used instead of a kernel-level IPC mechanism; despite how difficult it is to work with directly, Mach IPC is one of the hidden gems of NEXTSTEP through the Darwin family of platforms.

geofft 6y ago
There were multiple attempts at getting a D-Bus-style IPC into the Linux kernel, none of which have particularly succeeded. It seems like the userspace solution works totally fine, and it allowed D-Bus to actually ship to people and take off - especially because it was easier to figure out which IPC mechanism had the right model and iterate on features. And that's not to mention that a rich IPC mechanism in the kernel is necessarily a more intricate attack surface. Android's Binder RPC is in the kernel and it's had quite a few CVEs over the years. Actually it's kind of funny that Linux, the monolithic kernel, is the one where IPC is in userspace, and Mach, the microkernel, is the one where IPC is an unavoidable part of the kernel. (Especially because the overhead of unavoidable Mach RPC seriously hurt its market success chances, and Darwin made Mach RPC avoidable by bolting on a BSD syscall interface, making Darwin in some sense worse than monolithic.)
- eliaspro 6y ago
  I was really disappointed kdbus didn't make it into the Kernel (apparently for good reasons), as this would've solved so many issues. What I'm still trying to wrap my head around is Varlink's [1] role in all this since then. Is it supposed to make DBus obsolete at some point? What level of compatibility towards DBus does it offer? What's the driving force behind it's development? How widely was it adopted so far (I've seen at least a few usage references in systemd, such as for the user/group API [2])? [1] https://varlink.org/ https://varlink.org/ [2] https://systemd.io/USER_GROUP_API/ https://systemd.io/USER_GROUP_API/

geofft 6y ago

There were multiple attempts at getting a D-Bus-style IPC into the Linux kernel, none of which have particularly succeeded. It seems like the userspace solution works totally fine, and it allowed D-Bus to actually ship to people and take off - especially because it was easier to figure out which IPC mechanism had the right model and iterate on features. And that's not to mention that a rich IPC mechanism in the kernel is necessarily a more intricate attack surface. Android's Binder RPC is in the kernel and it's had quite a few CVEs over the years. Actually it's kind of funny that Linux, the monolithic kernel, is the one where IPC is in userspace, and Mach, the microkernel, is the one where IPC is an unavoidable part of the kernel. (Especially because the overhead of unavoidable Mach RPC seriously hurt its market success chances, and Darwin made Mach RPC avoidable by bolting on a BSD syscall interface, making Darwin in some sense worse than monolithic.)

eliaspro 6y ago
I was really disappointed kdbus didn't make it into the Kernel (apparently for good reasons), as this would've solved so many issues. What I'm still trying to wrap my head around is Varlink's [1] role in all this since then. Is it supposed to make DBus obsolete at some point? What level of compatibility towards DBus does it offer? What's the driving force behind it's development? How widely was it adopted so far (I've seen at least a few usage references in systemd, such as for the user/group API [2])? [1] https://varlink.org/ https://varlink.org/ [2] https://systemd.io/USER_GROUP_API/ https://systemd.io/USER_GROUP_API/