>> this idea has been bandied about a few times before, and i even started
>> trying to do it about 2.5 years ago (but shortly thereafter, i realized
>> that while i though i knew how i wanted to do it, i was actually not
>> sure).  strangely enough, i picked it up again about eight months ago
>> (almost two years to the day after i started the first time), but this
>> time i got it done.
>
>This is very good!

yes.  :)

>> my mental list of requirements were:
>> 
>> * sysctl(8) no longer has to be recompiled to be able to display new
>> entries (though it still will if the new entry is a "struct", not one of
>> the others, and you want it printed intelligently).  it would instead
>
>Why are structs needed? One would think that the sysctl tree is already
>structured enough.

ps, for example, uses sysctl to ask the kernel for a "large binary
bloc that describes a given set of (or all) processes".  this is a
"struct".  sysctl(8) can print a few of the simpler structs (see
kern.boottime or vm.loadavg for examples), but most of the structs are
for consumption by specific programs.

>> make use of a new sysctlnametomib() function and/or walk the tree by
>> itself, learning it on the fly. 
>
>How exacly will the sysctlnametomib() function work? Will it read some
>configuration files with MIB definitions, like in SNMP? How will walking
>the tree work? Will the kernel know the MIB names and present it to the
>userland via some API?

sysctlnametomib() will use sysctl() to ask the kernel for the
name<->number mapping at a given level (eg kern.* or net.inet.*).  i
toyed with the idea of "caching" the mapping in a "database", but
never bothered actually to implement it, since sysctlnametomib()
caches the information itself.  calling sysctlnametomib() only once
has a certain cost, but as you call it more within a given process,
that cost is amortized.  walking the tree merely consists of getting
the top-level mapping, getting the mapping for the subtree you want,
and continuing downwars until you find the node you want, complete
with an expected size (eg ints are 4 bytes, u_quad_ts are 8, etc) and
a simple hint or two about presentation.  the kernel knows all the mib
names, except for the user subtree.  that's still implemented in libc.

hope this helps.  :)

-- 
|-----< "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."