Re: [GIT PULL] kdbus for 4.1-rc1

[Al Viro <viro@ZenIV.linux.org.uk>]

On Wed, Apr 15, 2015 at 03:54:10PM -0700, Andy Lutomirski wrote:
> Huh, interesting.
> 
> I was imagining that each of a server's peers (capability holders)
> would have a fresh struct file, but maybe this wouldn't be needed at
> all.  You'd still need a way to get replies to your request, but the
> API could just as easily be:
> 
> int send_to_capability(int dest, int source, const void *data, size_t len, ...);
> 
> where dest would be the destination's fd and source would be whatever
> receive queue I expect the response on.
> 
> So maybe this is feasible.  It doesn't solve broadcasts, but dbus
> unicast could easily layer over a facility like this and the context
> switch problem would go away for unicast.
> 
> Heck, I'd use it for my own proprietary stuff, too.  It would be way
> easier than the absurd tangle of socketpairs I currently use.

BTW, the main issue with AF_UNIX passing is that recepient isn't asleep
awaiting for descriptors - they are thrown by sender at whoever's receiving
and sit there until somebody gets around to picking them.

_IF_ we had
client: I want a desciptor <goes to sleep, interruptibly>
kernel: assign it a sequence number
server: sees request (including sequence number)
server: give this fd to originator of request #N
kernel: check if originator is still there, insert the damn thing into their
descriptor table if they still are and return the obtained number
or
server: tell the originator of request #N to fuck off
kernel: check if originator is still there and gleefully pass the "fuck off" if
they still are

we wouldn't have the in-flight state at all, and there goes the garbage
collection shite.  With some elaboration, it could even carry the
authentication traffic - "fuck off" might be "answer this challenge", with
the next "I want a descriptor" carrying reply...