Subject: dynamic sysctl
To: None <tech-kern@netbsd.org>
From: Andrew Brown <atatat@atatdot.net>
List: tech-kern
Date: 11/12/2003 22:39:10
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.

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 make use of a new sysctlnametomib() function and/or walk the
tree by itself, learning it on the fly.

* it should be easier to add new nodes at any point, either by adding
a few lines or a short function to existing code and linking it into
your kernel, by an lkm when it is loaded, by inserting a pccard or
other removable device (which means the underlying driver actually
adds the entries when it detects the device being inserted), or on the
fly from the command line.  the latter would only be permitted at
securelevel zero, of course.

* said new nodes should be able to refer to existing kernel data
either by name or by address, be readable or writable, and maybe even
be "private" (meaning that only root could read/write to them).

* the requirement that you must be root to pass in data via
oldp/oldlen is silly and must go away.  whether you can pass data in
should be checked later on, once we know what you're going to do.

* the fact that certain objects are writeable but become read-only at
a certain securelevel will be handled "internally", but other
requirements (such port numbers must be in a specific range, or
securelevel can only be raised, or only lowered by init), will be
handled by helper functions that can do (just about) anything they
want.

* the api/abi should not change at all (modulo some errno values
shifting slightly), so that existing applications should have no
trouble using it in its new form.

* it should be incredibly complex and dense code, with absolutely no
comments and variable names that are too short and mean absolutely
nothing to anyone.

after about five minutes, i ditched the last requirement because it
made the other three decidedly unachievable.  ;-p

i've got most of it done (the native netbsd sysctl tree, the emulated
darwin and linux trees, and the netbsd32 "overlay" tree), but what i
haven't done yet is:

* the "new world order" cpu_sysctl() for any port except i386 -- this
shouldn't take all that much effort, but i don't have *anywhere* to
test any of it.  not really.  okay, i could test a few (four?), but i
still haven't done it yet.

* documentation -- sysctl(8) needs work to describe new flags and new
syntax, sysctl(3) needs to describe the new features of the api, and
sysctl(9) needs to be written from scratch.

* a short list of other "to do" items, mostly involving crude
regression testing to verify that the api is identical.

at one point, i groveled through all the archives, scribbled down all
the requirements people had for such a system, and either filed them
away as "no...not doing that" (a small number of them) or as "okay,
that part's done" (most of them), but i don't have that list any more.

so...if anyone wants to ask questions or toss out some comments (or
just fuel the fire :), please do so.  ideally i'll have the code in a
comittable form by next wednesday (right now it's a library that calls
into an lkm if you've loaded it, or just pretends real good if you
haven't), though that might be sans documentation for a little
while...

thanks.

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