2014-01-24 06:33:19

by Robert Schiele

[permalink] [raw]
Subject: [PATCH] use NFS4_MAXMINOR instead of hard coded number

In utils/nfsd/nfsd.c we used hard coded number 2 in option parsing
when referring to NFS4_MAXMINOR. We should use the defined constant
instead to honor changes to that constant.

Signed-off-by: Robert Schiele <[email protected]>
---

This is obviously a rather trivial patch but the hard coded number
hit me when trying to support various kernels with different support
levels.

utils/nfsd/nfsd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/utils/nfsd/nfsd.c b/utils/nfsd/nfsd.c
index a9d77ab..c129ee5 100644
--- a/utils/nfsd/nfsd.c
+++ b/utils/nfsd/nfsd.c
@@ -160,7 +160,7 @@ main(int argc, char **argv)
case 4:
if (*p == '.') {
int i = atoi(p+1);
- if (i > 2) {
+ if (i > NFS4_MAXMINOR) {
fprintf(stderr, "%s: unsupported minor version\n", optarg);
exit(1);
}
@@ -181,7 +181,7 @@ main(int argc, char **argv)
case 4:
if (*p == '.') {
int i = atoi(p+1);
- if (i > 2) {
+ if (i > NFS4_MAXMINOR) {
fprintf(stderr, "%s: unsupported minor version\n", optarg);
exit(1);
}
--
1.8.4


2014-01-24 19:28:31

by J. Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH] use NFS4_MAXMINOR instead of hard coded number

On Fri, Jan 24, 2014 at 07:32:02AM +0100, Robert Schiele wrote:
> In utils/nfsd/nfsd.c we used hard coded number 2 in option parsing
> when referring to NFS4_MAXMINOR. We should use the defined constant
> instead to honor changes to that constant.

While we're at it, is there any harm to letting NFS4_MAXMINOR be much
higher? That would save the need to rebuild nfs-utils just because you
want to test a kernel with new minor version support.

It's using an int (should that be an unsigned int?), so we could make
this sizeof(int).

--b.

>
> Signed-off-by: Robert Schiele <[email protected]>
> ---
>
> This is obviously a rather trivial patch but the hard coded number
> hit me when trying to support various kernels with different support
> levels.
>
> utils/nfsd/nfsd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/utils/nfsd/nfsd.c b/utils/nfsd/nfsd.c
> index a9d77ab..c129ee5 100644
> --- a/utils/nfsd/nfsd.c
> +++ b/utils/nfsd/nfsd.c
> @@ -160,7 +160,7 @@ main(int argc, char **argv)
> case 4:
> if (*p == '.') {
> int i = atoi(p+1);
> - if (i > 2) {
> + if (i > NFS4_MAXMINOR) {
> fprintf(stderr, "%s: unsupported minor version\n", optarg);
> exit(1);
> }
> @@ -181,7 +181,7 @@ main(int argc, char **argv)
> case 4:
> if (*p == '.') {
> int i = atoi(p+1);
> - if (i > 2) {
> + if (i > NFS4_MAXMINOR) {
> fprintf(stderr, "%s: unsupported minor version\n", optarg);
> exit(1);
> }
> --
> 1.8.4
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2014-01-27 14:34:21

by J. Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH] use NFS4_MAXMINOR instead of hard coded number

On Sat, Jan 25, 2014 at 05:23:28AM +0100, Robert Schiele wrote:
> On Fri, Jan 24, 2014 at 8:28 PM, J. Bruce Fields <[email protected]> wrote:
> > While we're at it, is there any harm to letting NFS4_MAXMINOR be much
> > higher? That would save the need to rebuild nfs-utils just because you
> > want to test a kernel with new minor version support.
>
> That does not work. This constant is used to generate the string to be
> thrown into the kernel and the kernel complains about items in the
> string it does not know about, even if they are disabled, like "-4.7".
> It would work if at the same time you got a patch into the kernel that
> it no longer complains about unknown items that are disabled.

That's a bug that was fixed by 93648ecc10bae7ed542056abb55f4b8f10ddbbb9
"nfsd: fix minorversion-choosing interface"

--b.

2014-01-25 04:23:28

by Robert Schiele

[permalink] [raw]
Subject: Re: [PATCH] use NFS4_MAXMINOR instead of hard coded number

On Fri, Jan 24, 2014 at 8:28 PM, J. Bruce Fields <[email protected]> wrote:
> While we're at it, is there any harm to letting NFS4_MAXMINOR be much
> higher? That would save the need to rebuild nfs-utils just because you
> want to test a kernel with new minor version support.

That does not work. This constant is used to generate the string to be
thrown into the kernel and the kernel complains about items in the
string it does not know about, even if they are disabled, like "-4.7".
It would work if at the same time you got a patch into the kernel that
it no longer complains about unknown items that are disabled.

Robert

2014-01-27 14:55:31

by Robert Schiele

[permalink] [raw]
Subject: Re: [PATCH] use NFS4_MAXMINOR instead of hard coded number

On Mon, Jan 27, 2014 at 3:34 PM, J. Bruce Fields <[email protected]> wrote:
> That's a bug that was fixed by 93648ecc10bae7ed542056abb55f4b8f10ddbbb9
> "nfsd: fix minorversion-choosing interface"

Ah, cool. Missed that one.

Thanks,
Robert

2014-01-27 14:57:22

by J. Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH] use NFS4_MAXMINOR instead of hard coded number

On Mon, Jan 27, 2014 at 03:55:29PM +0100, Robert Schiele wrote:
> On Mon, Jan 27, 2014 at 3:34 PM, J. Bruce Fields <[email protected]> wrote:
> > That's a bug that was fixed by 93648ecc10bae7ed542056abb55f4b8f10ddbbb9
> > "nfsd: fix minorversion-choosing interface"
>
> Ah, cool. Missed that one.

OK, good, then could you respin your patch to make the maximum the
maximum number of bits storable in the data type? Or would you like me
to?

--b.