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 0:09 UTC (Thu) by jspaleta (subscriber, #50639)
Parent article: The kdbuswreck

Championing the AF_UNIX approach now.. seems more than a little quixotic.. considering the documented history of the previous attempt in 2012 to make it work. I don't understand how it could be considered now, when it was allowed to stall out in 2012.

references:
https://lwn.net/Articles/482523/
and
https://lwn.net/Articles/504722/

What would be useful for me is trying to get my head around how the objections from the AF_UNIX based socket approach overlap with the current objections. What particular objections from the previous discussion has the new approach solved, what objections are entirely new, and what objections have persisted from one attempt to another.

I do find it interesting that I see Havoc showing up in this discussion again, basically repeating his personal testimony concerning design factors that I saw him talk about in 2012.
ref: http://lwn.net/Articles/505235/

Makes me wonder are we just seeing different objections now from people who were not actively involved in the merge proposal review of the previous effort? Different eyeballs now bringing different ideal solution into discussion?

Naively, if AF_UNIX approach was at all workable, and had support from those reviewing the patches, I would have thought it would have been beaten into shape in 2012-2013 when there was active interest in seeing that approach merged. I'm not saying championing now is deliberately gaming the system, but it seems like the AF_UNIX based approach was beaten to death already and it seems pretty counter productive and downright inhumane to go beat that particular dead horse any more.

-jef

to post comments

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) [Link] (1 responses)

> 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.

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.