Subject: Re: nore on disk stats
To: Charles Hannum <Charles-Hannum@deshaw.com>
From: Perry E. Metzger <perry@piermont.com>
List: tech-kern
Date: 11/14/1995 16:13:05
Charles Hannum writes:
>    Ick. I wouldn't mind having netstat use sysctl(), but I think that
>    going for SNMP is REALLY BAD here.
> 
> So it could use the local interface if a host name isn't specified.
> This is a detail.

Its not a detail. The day I see an ASN.1 compiler being used in the
NetBSD kernel build process (probably doubling its size) I move to
some other operating system. SNMP is gross. Its not
simple. Kernelizing a lot of it would be a Bad Thing, IMHO.

>    I would argue that rather than thinking in SNMP terms, we should take
>    the part that is good -- the idea of having sysctl() support returning
>    enough information that clients can walk its MIBs extensibly and
>    cleanly -- and put lots of other stuff in sysctl(). This has all the
>    advantages you cite and none of the SNMP cruft.
> 
> No; in fact, it has only one of the advantages I mentioned.  Notably:
> 
> 1) It would *not* be similar to an existing standard.
> 
> 3) We *would* have to write wrappers for everything made available
> through snmpd (which is the main reason snmpd doesn't exist in any
> particularly useful form).

Well, actually, there are several perfectly good snmpd's we could be
running -- both the gigantic ISODE snmpd and the (by comparison)
smaller CMU snmpd have been ported to BSDI at various points (and the
ISODE one actually used to refer to itself as the 4.4 SNMPd in its man
pages) so they should run without any problem if we wanted an snmpd.

> 4) Machines cannot be managed remotely, unless we also invent a new
> network protocol.

Having actually been one of the people who built the tools to run a
network of 5000 machines in 12 cities on three continents, I'll tell
you, quite confidently, that the issue is not stuff like SNMP *at
all*. Managing machines and managing the network infrastructure
require very different models, and the snmp based tools don't really
fix most of your real problems in handling such a network. To the
extent that you need snmp, well, we have snmp daemons that can run on
NetBSD.

> 5) Doing anything based on string matching will bloat the kernel code
> significantly.

ASN.1/BER ain't exactly svelte.

All things considered, this is a lot of design and implementation work
to solve a non-problem with a really ugly solution.

I'm really suprised at this suggestion, Charles, especially given your
penchant for extremely clean designs.

Perry