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

From: Eric W. Biederman
Date: Mon Oct 23 2006 - 11:15:40 EST


Kyle Moffett <mrmacman_g4@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/