Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758978AbaKUQxO (ORCPT ); Fri, 21 Nov 2014 11:53:14 -0500 Received: from mail-ig0-f182.google.com ([209.85.213.182]:34599 "EHLO mail-ig0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757926AbaKUQxK (ORCPT ); Fri, 21 Nov 2014 11:53:10 -0500 MIME-Version: 1.0 In-Reply-To: References: <1416546149-24799-1-git-send-email-gregkh@linuxfoundation.org> <1416546149-24799-7-git-send-email-gregkh@linuxfoundation.org> Date: Fri, 21 Nov 2014 17:53:09 +0100 Message-ID: Subject: Re: kdbus: add node and filesystem implementation From: David Herrmann To: Andy Lutomirski Cc: Greg Kroah-Hartman , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , Linux API , "linux-kernel@vger.kernel.org" , Daniel Mack , 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 Hi On Fri, Nov 21, 2014 at 5:35 PM, Andy Lutomirski wrote: > On Thu, Nov 20, 2014 at 9:02 PM, Greg Kroah-Hartman > wrote: >> From: Daniel Mack >> >> kdbusfs is a filesystem that will expose a fresh kdbus domain context >> each time it is mounted. Per mount point, there will be a 'control' >> node, which can be used to create buses. fs.c contains the >> implementation of that pseudo-fs. Exported inodes of 'file' type have >> their i_fop set to either kdbus_handle_control_ops or >> kdbus_handle_ep_ops, depending on their type. The actual dispatching >> of file operations is done from handle.c >> >> node.c is an implementation of a kdbus object that has an id and >> children, organized in an R/B tree. The tree is used by the filesystem >> code for lookup and iterator functions, and to deactivate children >> once the parent is deactivated. Every inode exported by kdbusfs is >> backed by a kdbus_node, hence it is embedded in struct kdbus_ep, >> struct kdbus_bus and struct kdbus_domain. >> >> Signed-off-by: Daniel Mack >> Signed-off-by: David Herrmann >> Signed-off-by: Djalal Harouni >> Signed-off-by: Greg Kroah-Hartman >> --- > > >> + >> +static struct file_system_type fs_type = { >> + .name = KBUILD_MODNAME "fs", >> + .owner = THIS_MODULE, >> + .mount = fs_super_mount, >> + .kill_sb = fs_super_kill, >> +}; > > Does this want something like: > > .fs_flags = FS_USERNS_MOUNT Yes, we should add that. Nice catch! > This design may have the annoying property that, if a namespace-based > sandbox wants to use kdbus itself, it will need to proxy anything from > the parent that it wants to use. > > Is there a good reason why individual *busses* don't show up in the > filesystem? If they did, maybe they could be bind-mounted or > otherwise arranged to cross namespace boundaries. Buses show up as directories in kdbusfs. You can bind-mount them anywhere you want and you will get access to the endpoints in there. Thanks David -- 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/