Messages in this thread | | | Date | Mon, 5 Jan 1998 22:33:04 GMT | From | "Stephen C. Tweedie" <> | Subject | Re: sysctl() considered harmful |
| |
Hi,
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.
| |