Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756380AbbDOWyt (ORCPT ); Wed, 15 Apr 2015 18:54:49 -0400 Received: from mail-lb0-f176.google.com ([209.85.217.176]:35314 "EHLO mail-lb0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754720AbbDOWyc (ORCPT ); Wed, 15 Apr 2015 18:54:32 -0400 MIME-Version: 1.0 In-Reply-To: <20150415224854.GQ889@ZenIV.linux.org.uk> References: <20150415084812.GG16381@kroah.com> <20150415122555.74258d63@lxorguk.ukuu.org.uk> <20150415154551.GE6801@home.goodmis.org> <20150415163520.GA25105@kroah.com> <20150415130649.6f9ab20f@gandalf.local.home> <20150415173145.GA26146@kroah.com> <20150415225611.0c256ea6@lxorguk.ukuu.org.uk> <20150415221804.GP889@ZenIV.linux.org.uk> <20150415224854.GQ889@ZenIV.linux.org.uk> From: Andy Lutomirski Date: Wed, 15 Apr 2015 15:54:10 -0700 Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: Al Viro Cc: One Thousand Gnomes , Greg Kroah-Hartman , Steven Rostedt , Richard Weinberger , "Eric W. Biederman" , Linus Torvalds , Andrew Morton , Arnd Bergmann , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2706 Lines: 57 On Wed, Apr 15, 2015 at 3:48 PM, Al Viro 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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/