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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
