From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:36140 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750985AbeFDP7k (ORCPT ); Mon, 4 Jun 2018 11:59:40 -0400 Date: Mon, 4 Jun 2018 16:59:37 +0100 From: Al Viro To: Miklos Szeredi Cc: David Howells , Christoph Hellwig , linux-fsdevel , linux-afs@lists.infradead.org, LKML , Linux API Subject: Re: [PATCH][RFC] open_tree(2) (was Re: [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8]) Message-ID: <20180604155937.GI30522@ZenIV.linux.org.uk> References: <152720691829.9073.10564431140980997005.stgit@warthog.procyon.org.uk> <20180601062654.GA32397@infradead.org> <7067.1527841663@warthog.procyon.org.uk> <20180602030913.GU30522@ZenIV.linux.org.uk> <20180602034255.GV30522@ZenIV.linux.org.uk> <21804.1527954321@warthog.procyon.org.uk> <20180602174957.GX30522@ZenIV.linux.org.uk> <20180603005532.GZ30522@ZenIV.linux.org.uk> <20180604155205.GH30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180604155205.GH30522@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Jun 04, 2018 at 04:52:05PM +0100, Al Viro wrote: > On Mon, Jun 04, 2018 at 12:34:44PM +0200, Miklos Szeredi wrote: > > > fsopen = create fsfd > > fsmount = fsfd -> mountfd & set attr on mountfd & attach mountfd > > fspick = path -> fsfd > > move_mount = attach mountfd or move existing > > fsinfo = info from path > > open_tree = new mountfd from path or clone > > mount_setattr = set attr on mountfd > > > > Notice that fsmount() encompasses mount_setattr() + move_mount() > > functionality. Split those out and leave fsmount() to actually do > > the "fsfd ->mountfd" translation? > > Might make sense. FWIW, to make it clear: fsmount(2) in this series actually does *NOT* attach it to the tree. Commit message definitely needs updating - as it is, it's +SYSCALL_DEFINE5(fsmount, int, fs_fd, unsigned int, flags, unsigned int, ms_flags, + void *, reserved4, void *, reserved5) PS: IMO these reserved... arguments are in bad taste; if anyone has good reasons for that practice in ABI design, I'd like to hear those.