Re: [GIT PULL] kdbus for 4.1-rc1

[Andy Lutomirski]

On Wed, Apr 15, 2015 at 3:48 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Apr 15, 2015 at 03:28:58PM -0700, Andy Lutomirski wrote:
>> On Wed, Apr 15, 2015 at 3:18 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>> > On Wed, Apr 15, 2015 at 03:11:17PM -0700, Andy Lutomirski wrote:
>> >
>> >> This is functionally identical to passing AF_UNIX socket fds over
>> >> SCM_RIGHTS, but I want something much lighter weight.
>> >
>> > Most of the weight in SCM_RIGHTS comes from the fact that you can
>> > pass AF_UNIX sockets over it, which requires a garbage collector.
>> > Exclude that and suddenly it becomes very cheap...
>>
>> I should have been more specific.  I don't mean the performance of
>> SCM_RIGHTS itself; I mean the memory overhead of keeping tons of fds
>> around, each with their socket data structures and buffers.
>>
>> I think that dbus could be quite efficiently implemented with a
>> userspace daemon that just introduces peers to each other, but the fd
>> explosion could be rather bad for some use cases.
>>
>> I'll be the first to admit that I don't have a clean API in mind.
>> There was a lightweight fd proposal way back when, but it never went
>> anywhere, and it might not be suitable anyway.
>
> Wait, are you talking about the overhead of descriptors used for capability
> tokens (essentially zero - one system-wide struct file per capability +
> one pointer in descriptor table of anyone who holds it + two bits in
> bitmaps in the sam descriptor tables) or about the overhead of descriptors
> used to send/receive those over?  The latter don't have to be sockets
> at all - they could bloody well be files on some ipcfs, or character device,
> or FIFOs, etc.

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.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/