Subject: Re: Replacing the sysctl() interface.
To: "Charles M. Hannum" <email@example.com>
From: Chris G. Demetriou <firstname.lastname@example.org>
Date: 06/05/2000 12:07:15
email@example.com ("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
'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.