Re: mount default minor version behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 13, 2014 at 01:52:09PM -0500, Trond Myklebust wrote:
> On Thu, Nov 13, 2014 at 12:57 PM, Steve Dickson <SteveD@xxxxxxxxxx> wrote:
> > On 11/12/2014 05:42 PM, Trond Myklebust wrote:
> >>>> NFS v4.0, 4.1, and 4.2 are all part of the same module, though.  Is there a way to analyze modules and determine what is compiled in?
> >>> > Maybe come up with some global bit field could be used?
> >>> > Each bit signifies a minor version is enabled...
> >>> >
> >> No. This means that mount.nfs now suddenly needs to know the names of
> >> the NFS modules and how to load them before it calls mount() just so
> >> that it knows which parameters to try. This is a rathole we don't want
> >> to explore...
> > I don't think mount.nfs needs to know any names... Just
> > a file /proc/fs/nfs/mount that tells mount.nfs where
> > to start the negotiation....
> >
> 
> The kernel does not have that information until the NFSv4 module is loaded.

I still don't get it.  All it needs to know is an upper bound--that
could be a single compile-time constant.  Is there any reason not to
build that number into the main nfs module?

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux