Re: [PATCH] VFS autmounter support v2

Mike Waychison
2003-06-19T16:43:28Z

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