On Thu, Jan 17, 2008 at 06:10:55PM -0500, Jeff Layton wrote:
> On Thu, 17 Jan 2008 07:16:47 -0500
> Steve Dickson <[email protected]> wrote:
>
> > During my travels I found a small typo in nfsd_vers() (the routine
> > used by rpc.nfsd to set the protocol version(s) in NFS server)
> >
> > When testing to see which versions are available, nfsd_vers() should
> > use nfsd_versions[] not nfsd_version[]. The reason this typo is
> > not noticeable is due to the fact this availability info is used in
> > a reply that rpc.nfsd ignores.
> >
> > steved.
> >
> >
> > Author: Steve Dickson <[email protected]>
> > Date: Thu Jan 17 06:50:57 2008 -0500
> >
> > In nfsd_vers() the NFSD_AVAIL command should be using nfsd_versions[]
> > not nfsd_version[]
> >
> > Signed-off-by: Steve Dickson <[email protected]>
> >
> > diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
> > index 1190aea..f0c66e0 100644
> > --- a/fs/nfsd/nfssvc.c
> > +++ b/fs/nfsd/nfssvc.c
> > @@ -134,7 +134,7 @@ int nfsd_vers(int vers, enum vers_op change)
> > case NFSD_TEST:
> > return nfsd_versions[vers] != NULL;
> > case NFSD_AVAIL:
> > - return nfsd_version[vers] != NULL;
> > + return nfsd_versions[vers] != NULL;
> > }
> > return 0;
> > }
>
> This doesn't look right to me. With this, NFSD_TEST and NFSD_AVAIL do
> exactly the same thing. Why do we need both?
>
> It also changes the output of /proc/fs/nfsd/versions. It should show a
> number for every version compiled into the kernel, with a corresponding
> + or - depending on whether that version is enabled. With this patch,
> it'll only ever show versions that are enabled, never ones that are
> compiled in and disabled.
Oops, looks to me like you're correct--so nfsd_version[] is the versions
which this kernel was built to support, and nfsd_versions[] is the
subset of those that the server is currently accepting?
We could maybe give those two arrays names that were more helpful....
--b.
On Fri, 18 Jan 2008 17:06:41 -0500
"J. Bruce Fields" <[email protected]> wrote:
>
> We could maybe give those two arrays names that were more helpful....
>
That would be a definite improvement :-)
--
Jeff Layton <[email protected]>