>> Also any other feedback on what changes and improvements 9mount might
>> need before it can be made part of p9p (or maybe shipped with the
>> standard linux mount(1) tools?).
>
> I'll take a look today so I'm up to date on the current station and
> let you know. Basically it will probably be best to structure it as a
> "mount helper" and ship it in its own package. IIRC all the other
> mount helpers (with the possible exception of NFS) ship independently.
>
It looks like a really good start. It'd be nice to have something
which supported the virtio transport as well as there is going to be
an influx of those users shortly.
Lucho had a mount helper at one time that was able to use p9p to
authenticate when necessary -- this would be a nice feature to include
in the mount helper but is difficult to include without p9p as a
dependency.
It would be nice if 9mount and/or 9bind could do an unshare to create
a new namespace, but given the current Linux semantics, I'm not sure
you can get the right behavior (ie. 9mount will have its own name
space, but then the mount won't be visible in the shell which called
it).
Some support for the loose cache would be nice, and I don't see any
way of setting larger (or smaller) msize.
Options reflecting Lucho's access option should also be incorporated
to give users some flexibility there.
Most of these are enhancements that shouldn't stand in the way of a
packaging and submission to the distros....
The only thing you need to do for them is rename the executable to
match the mount helper format (mount.9p)
and install it in /sbin.
Not sure if there are any other requirements for mount helpers, but
easy enough to test ;) If you need additional examples look at
mount.cifs or mount.fuse -- looks like cifs has a umount helper as
well....
-eric
