Messages in this thread | | | Date | Thu, 19 Jun 2003 12:53:30 -0400 | From | Mike Waychison <> | Subject | Re: [PATCH] VFS autmounter support v2 |
| |
viro@parcelfarce.linux.theplanet.co.uk wrote:
>On Thu, Jun 19, 2003 at 11:13:42AM -0400, Mike Waychison wrote: > > > >>Introducing special trap vfsmounts w/o super_blocks means we can no >>longer have arbitrary actions on those traps. AFS wants to define what >>happens in kernelspace, autofs wants to define it in userspace. Last I >>checked, vfsmount doesn't have an ops structure. >> >> > >It would have send an event over attached opened file. Attached at >creation time. > That's a pretty good idea then :)
> > > >>This only works for mounts performed in kernel space. It doesn't lend >>itself to performing mounts in userspace and would force autofs to >>re-implement mount(1) parsing/struct packing in kernelspace. Definitely >>not a good solution. >> >> > >Or if passed event contains opened mountpoint-to-be. > By this, I assume you are implying that infrastructure for mounting on a given struct file (w/ S_ISDIR) would be made. Correct?
How would this kind of trap be installed in userspace? 'mount -t trap -o fd=# none /trappoint' which gets caught by the vfs layer in a special manner I suppose? The vfs system would of course be responsible for pipe errors/closure. As well, the passed opened mountpoint-to-be would have to be owned by the process owning the reading end of the pipe.
> > > >>I'm still partial to the idea that a usenamespace ioctl on >>/proc/<pid>/mounts is a cleaner solution in the long run, both for >>automounting as well as for administration tools. >> >> > >Vetoed. ioctl() is _not_ an acceptable way to implement any generic >functionality. It basically says "my interface is a garbage". >
Alright. Automounting aside, does it still make sense to have *some* way for a sys-admin to join an existing namespace? sys_pushns(pid_t pid)/sys_popns() perhaps? Administrating an environment with multiple running namespaces may become difficult to administer without such capability.
> >And yes, we need to think about a new syscall for mount-related >work. With sane API - mount(2) one is _not_. sys_mount() would >still stay, obviously. >
What is not sane about mount(2)? Are you talking about the move/bind/remount functionality?
Mike Waychison
- 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/
| |