Subject: Re: dynamic sysctl
To: David Laight <>
From: Andrew Brown <>
List: tech-kern
Date: 11/18/2003 08:51:28
>> >> >Why not just make:
>> >> >	sysctl((void *)"kern.maxproc", 0, &buf, sizeof buf, NULL, 0);
>> >> >return the value of kern.maxproc (etc).
>> >> 
>> >> sounds nice, but how does that communicate the type of the returned
>> >> data to the caller?  or maybe buf could then consist of a type number,
>> >> followed by a length number, followed by the actual data...
>> >
>> >Well, in most cases (ie everything except the sysctl program) the
>> >caller knows what he expects. For sysctl maybe "kern.?" could return
>> >the types of the subfields
>> >- better have 'kern.*' return ""
>> most cases (ie, everything except the sysctl program) the
>> caller knows where the thing is that he's looking for, and does not
>> have to do auto-discovery.
>Except that it is safer to use the kernel's map of name => number, rather
>than have some programs using the kernel's map and others the header
>file.  Especially if you don't know whether the item has a fixed name
>or a dynamic one.

you misunderstand me.  i did not mean to imply that programs should
continue to use:

	int name[2], namelen = 2;
	name[0] = CTL_KERN;
	name[1] = KERN_SECURELVL;
	sysctl(&name[0], namelen, ...

though that's still supported.  it's better, imho, to do this:

	int name[2], namelen = 2;
	sysctlnametomib("kern.securelevel", &name[0], &namelen,
	sysctl(&name[0], namelen, ...

(though i've grown particularly fond of merely using 1.9 on the
command line to represent kern.securelevel -- it's a lot lesss
typing :).

that uses the kernel's name<->number mapping and not the header file
and the program continues to "know" what it's asking for.

>The run-time cost in cpu cycles should be trivial. From a coding point
>of view sysctl_read("kern.maxproc", &buf, sizeof buf) would be less
>error prone than the current scheme. could easily do that as a library call at this point, and
kern.maxproc ain't moving...  :)

fwiw, i stand by my point that while entries in the sysctl mib could
be added and removed very rapidly, i don't think that will or should
happen, since anything incredibly short-lived is almost completely
useless.  such data should have a different interface.

>Maybe, in time, the numbers could be depracated....

sure, though the sysctl() interface would have to be abandoned at that
point in favor of something else.

|-----< "CODE WARRIOR" >-----|             * "ah!  i see you have the internet (Andrew Brown)                that goes *ping*!"       * "information is power -- share the wealth."