Miklos Szeredi wrote:
>>>> After a successful mount, the NFS mount command tucks some options into 
>>>> /etc/mtab that reflect which mountd was used for the mount, and what 
>>>> protocol version and port was used for the mount request.  Those options 
>>>> are not passed to the kernel, and do not appear in /proc/mounts today. 
>>>> See nfs(5)'s discussion of the mountport, mounthost, mountprog, and 
>>>> mountvers options.
>>>>
>>>> However, the trend for NFS is to push mount option parsing into the 
>>>> kernel.  Thus all options will be passed to the kernel, and at that 
>>>> point it should be able to reflect the mount* options in /proc/mounts. 
>>>> But it doesn't do that quite yet.
>>> Trond, do you have a roadmap for this?
>> Well I'm actually doing the coding, and Trond is playing more of an 
>> architectural role.
> 
> OK, what your estimage for this then?

I don't have an estimate.  This is all very slippery because once I get 
into a part of the code, we discover a lot of issues that we didn't 
expect.  The NFS mount stuff is largely historical; we've all forgotten 
(or never really knew) how it works.

> It would be nice to have all this stuff in 2.6.24, which doesn't leave
> a lot of time.

Yes, that would be nice, but there's a lot of stuff that needs to get 
done before this.  NFS IPv6, for example, is a higher priority than 
refactoring to remove /etc/mtab -- the US government has a new 
requirement in 2008 for IPv6 support in any software that it purchases, 
and NFS may be a stumbling block for distributors if it doesn't have it.

So I'd say "no way" for 2.6.24, but it's really Trond's call to make.

> But if it's just those four options you mentioned, it should be
> managable.  I do not think there needs to be some generic code to
> hande userspace-only options, it would be perfectly fine just to
> parse, store and show them like all the other options.

Like you, I don't expect it will be difficult to implement, but I have 
too many balls in the air to make any promises at the moment.  Plus, we 
can't really predict when distributors will feel the in-kernel mount 
parsing stuff will be ready for their users.