[ On , June 5, 2000 at 11:34:18 (-0700), Chris G. Demetriou wrote: ]
> Subject: Re: Replacing the sysctl() interface.
>
> wrstuden@zembu.com (Bill Studenmund) writes:
> > The real win with using an fs interface is that the kernel is in charge of
> > turning mib names into locators.
> 
> of course, this is also solved if you pass the MIB-ish names into the
> kernel, and let it do the right thing.  8-)
> 
> in my opinion, that's the way to go.  the only particularly
> interesting thing about it is that you have to have a way to get the
> names out of the kernel, but that's easy enough: either just a query
> at a given 'directory' level returns the names, or have a special node
> for each 'directory' which returns the names...

Hmm... sounds an awful lot like a filesystem again!  ;-)

Why this (IMHO) "insane" resistance to the obvious?  Once you go the
filesystem route the advantages only multiply as more and more tools are
able to do things they already know how to do to find out information in
the kernel, and indeed in some cases to change that information.

In terms of portability there are still issues with the format of the
data that are returned from a filesystem interface, and indeed a non-FS
interface gives the advantage of making it relatively easy to document
the data formats using supplied structure definitions or whatever that
are easily included in programs using the interface.  But I think that's
just a lame excuse!  :-)  Making the data formats portable and easy to
parse forces a certain amount of extra attention to be paid to them and
I think that's a very good thing to do!  BTW, I do intend to imply that
simply moving sysctl() to a virtual-FS without at the same time making
most of the data it reads and writes be more human friendly (perhaps
/sysctl/binary/.... could be reserved to more efficiently handle more
complex system specific binary data structures that would be described
by C structure declarations in .h files).

In my opinion a full in-kernel SNMP implementation is the only viable
alternative to a virtual filesystem and that sysctl() as it stands is
indeed long past being declared obsolete.  However I'm not sure I want
to go the SNMP route either -- it seems unnecessarily complex even
though it affords a very portable description of the data formats and it
is easily extensible.  Note that even with a virtual-FS foundation it's
still possible to put a full user-level SNMP agent on top that can be
just as dynamic and run-time extensible....

BTW, my reading of the relevant sections in "The Desing and Impl. of the
4.4BSD OS" (McKusick et al) leads me to think that sysctl() was an
experimental thing and if it were continued it would go the route
towards becoming something much more like SNMP.  It also seems to me
that /kernfs and /procfs were highly enough regarded that a virtual FS
would be the alternative to taking sysctl() down the SNMP road.  Perhaps
if any of the authors of that book (or their "former" co-workers) are
lurking on this thread they could give us their current thoughts on this
topic.

As always though there's the (perhaps minor) need to consider what the
other *BSDs are doing and planning to do, at least to the extent that
binary compatability is necessary or desired.  It seems to me that the
existing sysctl() features are rarely used by portable binary
applications, but perhaps that's simply because it's not really
portable.  I note that many linux applications make use of their
equivalent virtual filesystem(s) on a regular basis.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>