In some email I received from Johan Danielsson, sie wrote:
> Darren Reed <darrenr@reed.wattle.id.au> writes:
> > In some email I received from Johan Danielsson, sie wrote:
> > > Darren Reed <darrenr@reed.wattle.id.au> writes:

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

> > > I think this should be done by having a function that is called when
> > > someone is trying to set a value. That way you can enforce arbitrary
> > > restrictions on values.

> > There are a few "specials" (such as securelevel) which would be
> > handled in this way, but the number of other "tuneables" for which
> > this can be applied weights strongly in favour of generic support.
> 
> There is nothing that prevent you from supplying a set of standard
> functions.

I don't think I've been very clear here.  The idea is to have a "standard"
function that would deal with all "int" (say) types of data in the sysctl
tree.  That would deal with min/max properties.

For others, where you want to confine it to being in lots of 1000 or it
must always increase, a separate function would be called to "verify" that
the new value is acceptable.

As a result of having a "default" value stored, I would like to see the
possibility of walking the sysctl tree and retrieving defaults, allowing
a diff to be performed on output from current vs default values.  It would
also provide a mechanism for sysctl to "reset" an entry to the default
value, whatever that may be.  Of course, such a reset would be subject
to the value being valid, lest something like securelevel be reset from
current back to 0 :-)

Darren