root@ihack.net ("Charles M. Hannum") writes:
> * Using a non-fs interface with actual names also introduces a fair
>   amount of overhead and bloat -- but not as much.  It has the
>   additional performance problem of causing you to re-walk the
>   hierarchy (with massive numbers of strcmp()s) every time you fetch a
>   value, unless you add another set of iteration primitives.

well, i suppose you might define hash-based lookup of names 'another
set' ... but in general, what you really want is 'lookup/iterate at
this level' ops, anyway; you don't want everybody just trundling thru
the data structures with queue macros.


> Really, given the way the world works today, and the simply fact that
> site managers generally *want* SNMP support, the right thing to do is
> to merge our sysctl(2) MIB with SNMP.  The user API would be almost
> the same as it is today, but it would require no extra name
> translation for SNMP.  The internal implementation could of course be
> anything we want; adding a pluggable interface would be fairly
> trivial.

'adding a pluggable interface' (for some definition thereof) is what's
most interesting to me.

You should be able to have a sysctl tree per device, per mounted file
system, etc, to tweak the parameters of devices/filesystems/etc.

if you can do that via standard SNMP MIBs, great.  If you can't, then as
far as I'm concerned, standard SNMP MIBs aren't up to the task.


cgd