On Wed, Apr 15, 2015 at 4:27 PM, Al Viro <v...@zeniv.linux.org.uk> wrote: > 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...
I wonder if we could get away with having the receiver pre-allocate some placeholder fds and then have the kernel replace a placeholder with a passed fd immediately when the fd is sent and enqueue *that* in the cmsg data. If you send an fd to someone who hasn't assigned any placeholders to the receiving socket, then you get an error. To keep the accounting sane, a placeholder would be a bona fide fd, presumably a reference to a global placeholder anon_inode. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/