The impasse in the kdbus discussion: Did we learn nothing from AF

The impasse in the kdbus discussion: Did we learn nothing from AF_UNIX attempt?

Posted Apr 23, 2015 12:36 UTC (Thu) by daniels (subscriber, #16193)
In reply to: The impasse in the kdbus discussion: Did we learn nothing from AF_UNIX attempt? by jspaleta
Parent article: The kdbuswreck

> Naively, if AF_UNIX approach was at all workable, and had support from those reviewing the patches

It didn't, and don't see how it ever would: http://thread.gmane.org/gmane.linux.kernel/1255575

David made it pretty clear that he doesn't feel the kernel has any role providing a socket subsystem which provides a multicast subscription model or in-order/guaranteed delivery, and suggested using multicast UDP instead. Which might almost work (substantial overhead to reassemble notwithstanding) if it supported fd passing, which it obviously doesn't.

His other suggestion was turn D-Bus into a network-capable protocol. Again, where that leaves fd passing is anyone's guess.

So it's pretty clear that nothing even resembling a general IPC system which has enough benefit to be usable for D-Bus will ever make it through net/. And here we are.

If you were some totally different IPC system with totally different requirements, you might stand a chance of being able to use a lossy, out-of-order, multicast protocol though.

to post comments

The impasse in the kdbus discussion: Did we learn nothing from AF_UNIX attempt?

Posted Apr 25, 2015 17:26 UTC (Sat) by ploxiln (subscriber, #58395) [Link]

From that posting:

"The first approach was to create a new AF_DBUS socket address family and
move the routing logic of the D-bus daemon to the kernel. The motivations behind
that approach and the thread of the patches post can be found in [1] and [2].

The feedback was that having D-bus specific code in the kernel is a bad
idea so the second approach was to implement multicast Unix domain sockets so
clients can directly send messages to peers bypassing the D-bus daemon."

So now that kernel developers are trying to fend off what amounts to a lot *more* "D-bus specific code in the kernel", AF_BUS is a lot more appealing. If two years ago they said "... and if not this, we're going to get in a D-bus specific monstrosity via GregKH", and the core kernel devs believed it, they might have put a lot more pressure on DaveM to let something minimal through.

But now, D-bus proponents are unlikely to let go of their perfect-fit subsystem, the result of a lot of work, and which seemed so close to getting in.