On Mon, 5 Jan 1998 12:08:16 +0100 (MET), Andries.Brouwer@cwi.nl said:
> The names that sysctl() uses are arrays of integers.
> But the kernel variable addressed by such an array
> depends on the kernel version. Yucch!
Does it??? I've just looked at the sysctl.h from both 2.0 and the
latest 2.1 kernels, and the numbering there is the same in each case.
[OK, on double-check, there are discrepancies --- red alert! ]. If I
use a sysctl name array of, say,
[CTL_NET, NET_IPV4, NET_IPV4_FORWARD]
then it should refer to the same thing no matter which kernel it is built
on or which kernel it is executed on. This is the whole _point_ of
sysctl, and anything which violates that is broken! It doesn't matter
the name of variable that the sysctl entry points to, as long as the
same name refers to something with the same functionality in each kernel
version.
> So, any code that uses sysctl() instead of procfs
> must call uname() or so first, and have a built-in
> database with what integer names the various variables
> have in various kernels. And such a program will do
> random things next year when some kernel hacker has
> changed the numbers again.
Yes. Sysctl names should never change, although they may become
obsolete and new names may be added. The kernel will return a standard
error (ENOTDIR) if you give it a name it does not recognise. We need to
restore the 2.0 numbering and _stick_ to it. Bah.
> (And changing them was made easier by using enum's in
> 2.1.* instead of the #define's of 2.0.* - it seems so
> easy to insert something in a list.)
I should probably add a comment to the top of that include file to make
sure that people don't reorder the existing entries.
> Maybe we should throw out sysctl(), before some author
> thinks that she can use it.
> Andries
> Ref: compare sysctl.h in 2.0.33 and 2.1.77.
> E.g., what value has KERN_SECURELVL? and NET_IPV4_ARP_TIMEOUT?
14 and 4, and 13 and 5. Whoops. Somebody slipped in a bad 'un. We
should correct the 2.1 numbers ASAP, thanks for pointing this out.
Cheers,
Stephen.