Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> writes:

> frank wrote:
> > | There was a question from a vendor using NetBSD the other day, who
> > | was in need of a sysctl MIB for local use. The suggested top-level
> > | name was 'vendor', to be used only by vendor-extensions to NetBSD.
> 
> It would be useful to have an idea of what exactly they want to stuff
> in there.

I must admit that some parts of the stuff we want to put in there is
duplication of what's in NetBSD 1.5. Other parts are something that should
be in the generic NetBSD code. We want to get rid of libkvm.

Other things we put in there: hardware dependent reading of serial number
and product information from the chassis, interface-specific statistics,
controls, etc. (we decided that this fits better in sysctls than ioctls),
hardware "slot"[1] information (status, name, hw-dependent stuff, etc) and
some more. We also use the hardware sysctls for forced detach and reprobe
of pci devices (debugging pruposes mostly, but in the future we want
to have PCI hot-swap because we use cPCI).

One of the biggest reasons for us to use sysctls is that this gives us one
place where all our local interfaces are stored and hopefully lets us avoid
collissions with mainstream NetBSD. We've had problems with our own syscalls
and char devices, so we decided that sysctl is good enough to access all this.

> The current sysctl implementation is (a) not very extensible, (b)
> assumes that the set of labels for any given MIB prefix is a small,
> more-or-less contiguous number space (not true for the IANA enterprise
> space), and (c) compiles the textual form of the MIB into the
> "/usr/sbin/sysctl" program and the numeric form into the kernel so it
> has to match in both places.

That's when you assume that we want to use /usr/sbin/sysctl.
We don't. We have our own configuration utilities. The only thing we take
from NetBSD is libc, init, sh, mount/fsck and the kernel.

We want to be able to register some sysctl number in NetBSD to avoid
future incompabilites. Stuffing things under "vendor" or "vendor.<magic>" or
"X.Y" should be good enough. As long as we know that mainstream NetBSD won't
use them (and hopefully noone else that we will merge code with).

//art

[1] Users like eth-X/Y better than fxpN, especially since we don't want to
    force configuration change when new hardware is added. And no, this
    code is not (and is probably impossible to do) generic enough for
    inclusion in NetBSD. We have heuristics for identifying our products
    depending on the pci configuration (don't ask) and hard-coded functions
    for mapping slot to bus and device.