3 ms·

> Would you prefer DBus to be implemented in the kernel Wasn't Greg KH himself trying to explore this? I think it was called Bus1.

by sph 2y ago

mort96 2y ago
My understanding is that kdbus was mostly a new transport mechanism, so that the dbus daemon didn't have to implement all of dbus's features on top of unix sockets? I don't think there was an attempt to put the whole daemon in kernel space, and there certainly wasn't talk of exposing DBus as a VFS AFAIK Though I haven't read about kdbus in a long time, so I might be misremembering or have misunderstood something back when I read about it. Regardless, I was asking what bheadmaster would've preferred, and if the answer is "the dbus daemon should have been implemented in kernel space and that's what kdbus was trying to do" then that's fine.
p_l 2y ago
kdbus etc. was all about making "faster" dbus back when the original dbus-daemon implementation was "too slow (for our corporate sponsors[1])" so there was unresearched push to put dbus into kernel. Involved special things, including even new syscalls (some I think even got refactored out and actually became part of the ABI). Ultimately it got nuked because the code was considered problematic, and performance turned out to not require kernel code. [1] AFAIK mainly automotive companies that were porting, for some reason, QNX IPC over to D-Bus instead of updating a pre-existing "QNX IPC on Linux" code, and I think Binder didn't surface fast enough for this porting effort.
- blucaz 2y ago
  No, performance wasn't the main reason (although that was a big part), it was mainly about race conditions. If userspace implements the bus, then only the half of userspace that comes up after the daemon can use it. Having a reliable IPC mechanism that is available from the moment PID1 is started was the goal. Sadly that was rejected, and Bus1 was too, because apparently it's really bad to have IPC primitives in the kernel, can't have that. Then of course 6 months later Google showed up with a few wheelbarrows of cash and Binder, and strangely all such objections evaporated and it was merged without a peep. Funny how these things go.
  - p_l 2y ago
    Binder predated (significantly![1] Depending on how you count, it predated D-Bus itself[2]) both Bus1 and kdbus projects, and unlike either of them included some extra features for more efficient IPC (like mentioned by me elsewhere ability to pass CPU quanta from caller to callee and back). Making it available from before init formed properly was, quite possibly, considerable part of why it never got merged. Kernel team had spent significant amount of work pushing out things to userland for cases like configuration et al. There's possible issue of applications failing when non-kernel-managed resource goes away, but honestly that's going to be a problem even for handling loss of service on the other end of the bus, too. Funny thing, IIRC, ultimately both kdbus and bus1 had same userland requirements as binder does, which is userland component to set it up and IIRC provide management information too. [1] Binder was mainlined (as experimental, but present in mainline) code in 2012, and made it into stable in 2015. kdbus started unnanounced development the same year, and was proposed for inclusion in 2014 [2] OpenBinder which became Android Binder had 1.0 release in 2005, a year before D-Bus' initial release. And that's not counting original Binder, which shipped for the first time to public in 1995
    - blucaz 2y ago
      By "making it available" it doesn't necessarily mean a fully-working, configured broker, but only having enough working primitives that you can bring up userspace without races, with requests that can immediately be accepted, even if not answered until a bit later. The stuff that we currently just cannot do with D-Bus, and that we have to reinvent protocols for. > Binder predated both Bus1 and kdbus projects It's not about when they started, it's about when they got merged/rejected. One got rejected because "ipc in kernel is bad", and some months later the other was merged because "ipc in kernel is good". One rule for thee...
      - p_l 2y ago
        That's my point: Binder got merged before kdbus started development. Also, I still don't see what kind of races you're getting other than having an init system too stupid to handle ordering for applications too stupid to handle graceful connections. (Looking at last version of kdbus docs, the main coherent argument about races is relevant only to how Unix sockets can't pass around authenticated metadata along the message)
throw_a_grenade 2y ago
kdbus was rejected 10 years ago by Linus as a penalty for misbehaviour of the main developer. Here's the exact Linus rant: https://lore.kernel.org/lkml/CA+55aFzCGQ-jk8ar4tiQEHCUoOPQzr-Mz+-LsPHCWZKryXZquQ@mail.gmail.com/ https://lore.kernel.org/lkml/CA+55aFzCGQ-jk8ar4tiQEHCUoOPQzr...

> Would you prefer DBus to be implemented in the kernel Wasn't Greg KH himself trying to explore this? I think it was called Bus1.

by sph 2y ago

> Would you prefer DBus to be implemented in the kernel Wasn't Greg KH himself trying to explore this? I think it was called Bus1.

mort96 2y ago

My understanding is that kdbus was mostly a new transport mechanism, so that the dbus daemon didn't have to implement all of dbus's features on top of unix sockets? I don't think there was an attempt to put the whole daemon in kernel space, and there certainly wasn't talk of exposing DBus as a VFS AFAIK Though I haven't read about kdbus in a long time, so I might be misremembering or have misunderstood something back when I read about it. Regardless, I was asking what bheadmaster would've preferred, and if the answer is "the dbus daemon should have been implemented in kernel space and that's what kdbus was trying to do" then that's fine.

p_l 2y ago

kdbus etc. was all about making "faster" dbus back when the original dbus-daemon implementation was "too slow (for our corporate sponsors[1])" so there was unresearched push to put dbus into kernel. Involved special things, including even new syscalls (some I think even got refactored out and actually became part of the ABI). Ultimately it got nuked because the code was considered problematic, and performance turned out to not require kernel code. [1] AFAIK mainly automotive companies that were porting, for some reason, QNX IPC over to D-Bus instead of updating a pre-existing "QNX IPC on Linux" code, and I think Binder didn't surface fast enough for this porting effort.

blucaz 2y ago
No, performance wasn't the main reason (although that was a big part), it was mainly about race conditions. If userspace implements the bus, then only the half of userspace that comes up after the daemon can use it. Having a reliable IPC mechanism that is available from the moment PID1 is started was the goal. Sadly that was rejected, and Bus1 was too, because apparently it's really bad to have IPC primitives in the kernel, can't have that. Then of course 6 months later Google showed up with a few wheelbarrows of cash and Binder, and strangely all such objections evaporated and it was merged without a peep. Funny how these things go.
- p_l 2y ago
  Binder predated (significantly![1] Depending on how you count, it predated D-Bus itself[2]) both Bus1 and kdbus projects, and unlike either of them included some extra features for more efficient IPC (like mentioned by me elsewhere ability to pass CPU quanta from caller to callee and back). Making it available from before init formed properly was, quite possibly, considerable part of why it never got merged. Kernel team had spent significant amount of work pushing out things to userland for cases like configuration et al. There's possible issue of applications failing when non-kernel-managed resource goes away, but honestly that's going to be a problem even for handling loss of service on the other end of the bus, too. Funny thing, IIRC, ultimately both kdbus and bus1 had same userland requirements as binder does, which is userland component to set it up and IIRC provide management information too. [1] Binder was mainlined (as experimental, but present in mainline) code in 2012, and made it into stable in 2015. kdbus started unnanounced development the same year, and was proposed for inclusion in 2014 [2] OpenBinder which became Android Binder had 1.0 release in 2005, a year before D-Bus' initial release. And that's not counting original Binder, which shipped for the first time to public in 1995
  - blucaz 2y ago
    By "making it available" it doesn't necessarily mean a fully-working, configured broker, but only having enough working primitives that you can bring up userspace without races, with requests that can immediately be accepted, even if not answered until a bit later. The stuff that we currently just cannot do with D-Bus, and that we have to reinvent protocols for. > Binder predated both Bus1 and kdbus projects It's not about when they started, it's about when they got merged/rejected. One got rejected because "ipc in kernel is bad", and some months later the other was merged because "ipc in kernel is good". One rule for thee...
    - p_l 2y ago
      That's my point: Binder got merged before kdbus started development. Also, I still don't see what kind of races you're getting other than having an init system too stupid to handle ordering for applications too stupid to handle graceful connections. (Looking at last version of kdbus docs, the main coherent argument about races is relevant only to how Unix sockets can't pass around authenticated metadata along the message)

throw_a_grenade 2y ago

kdbus was rejected 10 years ago by Linus as a penalty for misbehaviour of the main developer. Here's the exact Linus rant: https://lore.kernel.org/lkml/CA+55aFzCGQ-jk8ar4tiQEHCUoOPQzr-Mz+-LsPHCWZKryXZquQ@mail.gmail.com/ https://lore.kernel.org/lkml/CA+55aFzCGQ-jk8ar4tiQEHCUoOPQzr...