5 ms·

I wish DBus used a pseudo-filesystem approach with plaintext commands in a Plan9 manner - so you could call DBus object methods just by opening a file and writi

I wish DBus used a pseudo-filesystem approach with plaintext commands in a Plan9 manner - so you could call DBus object methods just by opening a file and writing/reading from it. There are probably reasons why DBus is implemented the way it is, but it just doesn't feel elegant at all.

actionfromafar 2y ago
It's the unix way /s COM (dbus) + Registry & services (systemd)
- pjmlp 2y ago
  While you are joking, COM was born out of the UNIX way, more precisely Distributed Computing Environment. https://en.wikipedia.org/wiki/Distributed_Computing_Environment https://en.wikipedia.org/wiki/Distributed_Computing_Environm... Then we had that great experience called Taligent https://en.wikipedia.org/wiki/Taligent https://en.wikipedia.org/wiki/Taligent And naturally CORBA, https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A... NeXTSTEP's Portable Distributed Objects https://en.wikipedia.org/wiki/Portable_Distributed_Objects https://en.wikipedia.org/wiki/Portable_Distributed_Objects Which inspired Sun's Distributed Objects Everywhere written in Objective-C, followed by its reboot in Java as Enterprise JavaBeans. https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere
mort96 2y ago
Would you prefer DBus to be implemented in the kernel then, or would you think that the DBus daemon should expose that pseudo-filesystem using FUSE? Neither of those things seems completely optimal to me to be honest. And it somehow feels very non-Linux that an open syscall or a readdir syscall should be able to block indefinitely as the desktop environment shows a permission syscall...
- 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.
blahgeek 2y ago
I guess it would be interesting to implement this for DBUS using FUSE.
XorNot 2y ago
Except Linux hasn't really done this for a while. Most things in Linux are managed via some type of message parsing these days anyway - i.e. you don't configure devices - really - by /dev/ entries, instead you use the /dev/ entry as the target for an ioctl call which basically does whatever it wants. It's not really file-like at all. Then there's network which is configured usefully by netlink, which is another message passing protocol. It doesn't seem like an accident that we keep reinventing socket-based messaging protocols to manage systems, and just "forgetting" to do it the Plan9 way.
- bheadmaster 2y ago
  From client perspective, socket I/O is isomorphic to the file I/O - you get a file descriptor and you read/recv and write/send to it. The only difference is how servers handle it. The ioctl() is different, mostly because it's used to share memory between kernel and userspace, but the same communication pattern could be implemented in file I/O too, probably with performance penalty. Just send the serialized structures, and receive them back. But the goal of DBus was never performance, it was to provide a unified interface to global system services. File I/O here seems like an obvious choice - it's the most fundamental interface that almost every program in the world supports.
mike_hearn 2y ago
Plan9 doesn't use plain text commands really. Look at how various services work and you'll find there's usually a C library wrapping the underlying pseudo-file. Plan9 was IMHO to a large extent a failed experiment; the filesystem API wasn't extended enough to be able to express enough operations (e.g. no transactions). The other problem with Plan9 style designs it the concept of filesystem servers. This kills off a lot more expressiveness still e.g. you can't move device files around to organize them better because they aren't really files and the layout is fixed by the server. A dbus that exported stuff via the FS would have the same problem. It'd be full of "files" that you can't rename, move, delete, add xattrs to, read, etc. Most of the operations you can do on files just wouldn't work so what's the point.

actionfromafar 2y ago

It's the unix way /s COM (dbus) + Registry & services (systemd)

pjmlp 2y ago
While you are joking, COM was born out of the UNIX way, more precisely Distributed Computing Environment. https://en.wikipedia.org/wiki/Distributed_Computing_Environment https://en.wikipedia.org/wiki/Distributed_Computing_Environm... Then we had that great experience called Taligent https://en.wikipedia.org/wiki/Taligent https://en.wikipedia.org/wiki/Taligent And naturally CORBA, https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A... NeXTSTEP's Portable Distributed Objects https://en.wikipedia.org/wiki/Portable_Distributed_Objects https://en.wikipedia.org/wiki/Portable_Distributed_Objects Which inspired Sun's Distributed Objects Everywhere written in Objective-C, followed by its reboot in Java as Enterprise JavaBeans. https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere

mort96 2y ago

Would you prefer DBus to be implemented in the kernel then, or would you think that the DBus daemon should expose that pseudo-filesystem using FUSE? Neither of those things seems completely optimal to me to be honest. And it somehow feels very non-Linux that an open syscall or a readdir syscall should be able to block indefinitely as the desktop environment shows a permission syscall...

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.

blahgeek 2y ago

I guess it would be interesting to implement this for DBUS using FUSE.

XorNot 2y ago

Except Linux hasn't really done this for a while. Most things in Linux are managed via some type of message parsing these days anyway - i.e. you don't configure devices - really - by /dev/ entries, instead you use the /dev/ entry as the target for an ioctl call which basically does whatever it wants. It's not really file-like at all. Then there's network which is configured usefully by netlink, which is another message passing protocol. It doesn't seem like an accident that we keep reinventing socket-based messaging protocols to manage systems, and just "forgetting" to do it the Plan9 way.

bheadmaster 2y ago
From client perspective, socket I/O is isomorphic to the file I/O - you get a file descriptor and you read/recv and write/send to it. The only difference is how servers handle it. The ioctl() is different, mostly because it's used to share memory between kernel and userspace, but the same communication pattern could be implemented in file I/O too, probably with performance penalty. Just send the serialized structures, and receive them back. But the goal of DBus was never performance, it was to provide a unified interface to global system services. File I/O here seems like an obvious choice - it's the most fundamental interface that almost every program in the world supports.

mike_hearn 2y ago

Plan9 doesn't use plain text commands really. Look at how various services work and you'll find there's usually a C library wrapping the underlying pseudo-file. Plan9 was IMHO to a large extent a failed experiment; the filesystem API wasn't extended enough to be able to express enough operations (e.g. no transactions). The other problem with Plan9 style designs it the concept of filesystem servers. This kills off a lot more expressiveness still e.g. you can't move device files around to organize them better because they aren't really files and the layout is fixed by the server. A dbus that exported stuff via the FS would have the same problem. It'd be full of "files" that you can't rename, move, delete, add xattrs to, read, etc. Most of the operations you can do on files just wouldn't work so what's the point.