In some email I received from Charles M. Hannum, sie wrote:
> 
> There are problems with all of the approaches mentioned, of course.
[...]
> * 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.
> 
> * With either of the above, you still have to translate everything in
>   snmpd.

Which is why I asked about MIBs separately.  I had in the back of my mind
being able to do _something_ to make SNMP an easier task.

Do we have a map of how SNMP objects onto the sysctl interface ?

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

It occurs to me that SNMP already provides name->number translation, so
that all is required for an interface to do here is translate numbers,
somehow, and if snmpd is already available for NetBSD, then that exists
also.  The only real advantage is if the SNMP MIB numbering scheme is
used internally within NetBSD.  I don't see this being a huge win unless
we have evidence of snmpd spending significant amounts of time taking
care of this above and beyond the ASN.1 crap.

I see no reason why an extensible internal sysctl in the kernel means
that using numbers to search is either slow or out-moded for core
variables which also fall under SNMP definitions.

Darren