Subject: Re: dynamic sysctl
To: Pavel Cahyna <email@example.com>
From: Andrew Brown <firstname.lastname@example.org>
Date: 11/14/2003 12:00:47
>> 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!
>> 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
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" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."