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
user-defined lkms.

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
on it.

> Some of changes I think are worthwhile making:
> 
> - do lookups on name, not integer (except for backward compat.)

As above.

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

> - where possible, remove up foo_sysctl() routines which just
>   deal with basic types and handle basic types in a more centralised
>   fasion.

We dealt with this at some level with basic types, but nothing too
fancy.

> - support run-time additions and removals from entries on the sysctl
>   tree.

As above.

> - 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!

Simon.