Subject: Re: Replacing the sysctl() interface.
To: Darren Reed <firstname.lastname@example.org>
From: Simon Burge <email@example.com>
Date: 06/05/2000 22:47:54
Darren Reed wrote:
> I'm musing over working on replacing the current sysctl with something
> that's much more flexible and supports (at the very least) it being
> dynamic in nature.
Luke and I were musing over this earlier this year but didn't get around
to doing anything serious.
In a nutshell, there were something like sysctl_enter() and
sysctl_remove() in the kernel to add and remove entries into a global
mib-type table where each element had a name that could be used
for lookups. MIB numbers were reserved, with some allocation for
At the user-level, there was sysctl_bymib() (the equivalent of the
current sysctl() call) and sysctl_byname(). There was also another
function like sysctl_next() which would walk down the current mib level.
You could descend levels when you got to a node and did a sysctl_next()
with a NULL current mib.
That's a rough summary, I'll see if I can dig up some of our notes
> Some of changes I think are worthwhile making:
> - do lookups on name, not integer (except for backward compat.)
> - support min/default/max/modulus(?) parameters for each sysctl entry.
> This would let you enforce 0/1 on "boolean" sysctl entries such as
> ip_forwarding, etc. I'm thinking about modulus so that you can
> enforce things like u-sec timers to be in lots of 1000, etc. For
> string types that are rw, this would be limited to default. Some
> other properties for nodes I'm thinking of are "ownership" (based
> on user/group) and permissions (rwxrwxrwx) so you can setup read
> only, read-write and write only sysctl nodes.
We had basic types, and an "opaque" type where a given function
pointer performed the work. Didn't have owners/modes, but neat
> - where possible, remove up foo_sysctl() routines which just
> deal with basic types and handle basic types in a more centralised
We dealt with this at some level with basic types, but nothing too
> - support run-time additions and removals from entries on the sysctl
> - the base sysctl "tree" would be somewhat bare (kern only?), with
> various subsystem init functions being responsible for populating it.
Same idea here. Maintain the list of init functions could be not
pretty. We need kernel .init sections!
> - given it would be dynamic in nature, providing a compatible interface
> with sysctl as it is now would require walking the entire tree.
sysctl_next() as above.
> - what needs to be done, if anything, to make it into a "MIB" that is
> more suited to SNMP means ?
As I understand SNMP we voilate that concept by having complex types.
Take my recent kern_proc2 sysctl - in a pure SNMP world, wouldn't each
structure element be a separete MIB entry?
> ...any other ideas ?
> If I can get some useful feedback (I may have picked a bad time for
> this O:) I'll post back in a week or so about what I'd like to do
> (proposal) for further comment before embarking on making it happen.
> I would engvisage it easily being done before 1.6 :)
I'd like to see this happen, and help make it so!