>> >> >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 "name:type.name:type"
>> 
>> and...in 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,
			NULL, NULL, NULL);
	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.

well...you 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" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."