Re: [PATCH 1/4] VFS: Add a VFS helper function vfs_remote_path_lookup()

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Apr 02, 2009 at 03:34:34PM -0400, Trond Myklebust wrote:
> > *OW*
> > 
> > I've missed that completely.  OK, may I see the users, please?
> 
> This is why I'm reluctant to call it unshare_mnt_namespace() and was why
> I was trying to limit the usage of the interface.

Ho-hum...  You know what, it *still* fits into unshare() model.  The thing
is, if you look at the origin of clone()/unshare() (i.e. Plan 9 rfork()),
there's the following group of flags:

   RFNAMEG    If set, the new process inherits a copy of the parent's
   name space; otherwise the new process shares the parent's name space.
   Is mutually exclusive with RFCNAMEG.
   RFCNAMEG   If set, the new process starts with a clean name space. A
   new name space must be built from a mount of an open file descriptor.
   Is mutually exclusive with RFNAMEG.
   RFNOMNT    If set, subsequent mounts into the new name space and
   dereferencing of pathnames starting with # are disallowed.

And analog of that sucker (RFCNAMEG) is just about what you are doing
(well, that + attaching your vfsmount as separate action).  So how about
about CLONE_CLEANNS and passing it in flags?  Linus, do you have any
objections against such a flag?  It'd give you a new instance of
rootfs (empty, obviously) as root and flip root/pwd to it.

The thing is, I really want it to make sense other than just a very
specialized wrapper around path lookup.  We *already* have a bunch of
places doing subsets of unshare()-and-save; would be nice to get it
right once and for all...

BTW, if we look into the original, there's also RFCFDG - "give it an empty
descriptor table".  Might be also interesting, but that's a separate story.