Re: [RFD][PATCH 2/2] sysctl: Implement CTL_UNNUMBERED

[ebiederm@xmission.com (Eric W. Biederman)]

Kyle Moffett <mrmacman_g4@mac.com> writes:

> On Oct 23, 2006, at 03:25:13, Eric W. Biederman wrote:
>> --- a/fs/lockd/svc.c
>> -/* Something that isn't CTL_ANY, CTL_NONE or a value that may  clash. */
>> -#define CTL_UNNUMBERED		-2
>> -
>
>> --- a/fs/nfs/sysctl.c
>> -/*
>> - * Something that isn't CTL_ANY, CTL_NONE or a value that may clash.
>> - * Use the same values as fs/lockd/svc.c
>> - */
>> -#define CTL_UNNUMBERED -2
>
>> +++ b/include/linux/sysctl.h
>>  #ifdef __KERNEL__
>>  #define CTL_ANY		-1	/* Matches any name */
>>  #define CTL_NONE	0
>> +#define CTL_UNNUMBERED CTL_NONE /* sysctl without a binary number */
>>  #endif
>
> This change looks totally broken.  Before this patch, CTL_UNNUMBERED  == -2, a
> number that isn't CTL_ANY, CTL_NONE, or a valid sysctl  number.  After this
> patch, CTL_UNNUMBERED == 0, or CTL_NONE.

Exactly.  The only reserved sysctl numbers we have are 0 and -1.

Until my previous patch there was on number you could place into the
sysctl table that meant we did not have a binary sysctl name.  0 was
the closest but since it terminated the table it is generally useless.
-2 was a hack attempting to implement that within in the confines of
the previous sysctl implementation.

Now that I have reserved ctl_name == 0 to explicitly mean no sysctl number
and require both ctl_name == 0 and procname == NULL to terminate a sysctl
table.  We can remove the hack that nfs had, because we actually have a clean
way of implementing it.

There are sysctl tables currently in existence that use -2 as the index
of a data entry so that was out.  Numbers around MIN_INT/MAX_INT are probably
still available to reserve for a new purpose globally but 0 seems perfectly
up to the job.

I kept the CTL_UNNUMBERED name because it seems a little clearer than CTL_NONE.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/