There are probably reasons why DBus is implemented the way it is, but it just doesn't feel elegant 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.
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.
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.
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...
Wasn't Greg KH himself trying to explore this? I think it was called Bus1.
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.
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.
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.
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
> 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...
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)
It didn't, it was merged in 2015, a year after or so. No, staging doesn't count, it's a dumping ground for all sort of things that do not see the light of day.
> Also, I still don't see what kind of races
Just because you don't see it, it doesn't mean it's not there. Do some research and you'll see it.
kdbus didn't even make it into staging. Project mainline put in some serious work to get where it got.
And quite probably part of it going better was not insisting on becoming mandatory solution for everyone. If anything, it might have been less "wheelbarrows of cash" and more conflicts involving kdbus principal developer and Linus.
> Just because you don't see it, it doesn't mean it's not there. Do some research and you'll see it.
The kdbus docs could do better job declaring why it's needed then.
You mean, because it would actually be _used_ somewhere in open source distributions (that is, not just deep inside some de-facto proprietary half-closed-source fork owned by a single mega-corp)? Yeah when things are hidden away in some cupboard in the basement it's much easier not to ruffle feathers. But yeah the LKML is bad today, but back then it was a veritable open-air cesspool
> The kdbus docs could do better job declaring why it's needed then.
Well, it's dead, so what's the point...
As for documentation...
Maybe that's part of why it's dead and buried.
You're the one claiming there are races when starting services, so it's your responsibility to justify that claim.
You've mentioned before that "If userspace implements the bus, then only the half of userspace that comes up after the daemon can use it", but any service manager that supports service dependencies could be configured to run the bus first, and only run the rest of the userspace after the bus is up.
COM (dbus) + Registry & services (systemd)
https://en.wikipedia.org/wiki/Distributed_Computing_Environm...
Then we had that great experience called Taligent
https://en.wikipedia.org/wiki/Taligent
And naturally CORBA,
https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
NeXTSTEP's 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