Date: Mon, 11 Jan 1999 20:16:49 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Nate Williams <nate@mt.sri.com>, committers@FreeBSD.ORG Subject: Re: Another approach... Re: sysctl descriptions Message-ID: <26405.916082209@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 11 Jan 1999 07:44:28 EST." <199901111244.HAA13985@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199901111244.HAA13985@khavrinen.lcs.mit.edu>, Garrett Wollman writes:
><<On Sun, 10 Jan 1999 21:52:11 -0700, Nate Williams <nate@mt.sri.com> said:
>
>> sysctl is too general to be documented. It would be like reading the
>> perl manpages in hopes of tring to figure out what trim() does. Yes,
>> you can find it, but it's not optimal for the many reasons already
>> outlined (maintainability, ease of use, etc...)
>
>I don't believe this to be the case. I've been thinking about what
>the right way to handle this might be since the latest flare-up. What
>follows is a significant departure from the opinion I've had on this
>subject in the past...
>
>I think, if we want to be serious about describing what's in sysctl(3)
>as a ``MIB'', we should sit down and write an ACTUAL MIB, i.e., a hunk
>of ASN.1 that is a *specification* for the information we wish to
>present.
It was my original intention to (ab)use sysctl to implement the relevant
bits of MIB-II such that a snmpd deamon would have a minimal amount of
work to do.
At the time it stalled on several things, one of which were that it would
indeed increase the size of our kernel significantly to add that number
of variables, and I seriously didn't expect the user community to be
sufficiently hooked on SNMP to appreciate the neatness of my approach.
As time has gone by, I'm not longer sure about the neatness either.
Right now uses of sysctl comes in the following general classes:
1. tweak handles for the kernel like "net.inet.tcp.rfc1644"
2. syscall/libfunc implementation like ntpgettime() and getcwd()
3. state monitoring like struct proc for ps
4. statistics like debug.freevnodes
As such I'm not dissatisfied with our current sysctl (mkII), it does
most of what we ask from it. (btw: We do have instances, but the sysctl
program doesn't know about them, check the "struct proc" stuff)
I'm not really sure I agree with Garrett about writing ASN.1 for
this stuff. For a FREEBSD-MIB: yes, but not for the kernel interface.
(BTW: our IANA registrered enterprise# is 2238)
I did have a sysctl mkIII working at one time, which operated out
of an opaque binary file, using a "vipw" like editing interface,
and it implemented persistence in sysctl, per system/user/session/process
search order and God knows what, and about the only thing I could
find to use it for was the TZ environment variable! Well, I'm
kidding, variant symlinks too, but the legitimate uses of it were
not as numerous as I had anticipated at least, and I therefore gave
up on it.
If we want to go down this route a "registry" is the term we're
talking about, and we should seriously design it. NT made some
bad mistakes we can learn a lot from.
What use would a registry be to us ? Well, primarily a persistent
memory for the kernel (editable by the user). The scsi system
could store the max number of openings to use for a specific disk
instead of having to learn the hardway on each boot (but would it
make sense ?) We could store default settings for tty devices (but
would it make sense ?) We could store IPFW rules (but does it make
sense ?) and so on...
Every time I have revisited this, I have concluded that it isn't
really "the UNIX way", it's "the Windows way". UNIX boots and
come up, and you configure it from there on each reboot. If
anything is a POLA not to be transgressed on, it is the ability
of a power-cycle and boot into single user mode to be repeatable.
The UNIX way, in other words is to not let the kernel know
what we're doing, until we tell it, on every boot.
That leaves in essence variant symlinks (as known from Apollo/Domain)
for instance:
ln -s '/usr/${arch}/bin' /usr/bin
and other such stuff. Getting the kernel to yank the "${arch}" from
the users environment would not be easy, if even the right thing to
do, so probably a special name-space for these variables might be
needed.
Summary: It's not clear to me if we currently have justification for
a real registry, on the other hand sysctl seems to be doing pretty
well. Streamlining the interface to sysctl could make it a breeze
for devices to use it as well.
Comments most welcome.
--
Poul-Henning Kamp FreeBSD coreteam member
phk@FreeBSD.ORG "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26405.916082209>