Date: Mon, 11 Jan 1999 14:46:08 -0500 (EST) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Nate Williams <nate@mt.sri.com>, committers@FreeBSD.ORG Subject: Re: Another approach... Re: sysctl descriptions Message-ID: <199901111946.OAA15004@khavrinen.lcs.mit.edu> In-Reply-To: <26405.916082209@critter.freebsd.dk> References: <199901111244.HAA13985@khavrinen.lcs.mit.edu> <26405.916082209@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Mon, 11 Jan 1999 20:16:49 +0100, Poul-Henning Kamp <phk@critter.freebsd.dk> said:
> 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)
The reason I suggested ASN.1 as a reasonable alternative is because it
already exists and is used for this purpose in SNMP, which means that
the tools to play with it have already been hacked and debugged by
Someone Else. The principal requirements as I see it are:
1) Specification of display syntax.
2) Support for enumeration types.
3) name-to-OID translation.
4) DESCRIPTIONs!
The module compilation procedure would take the ASN.1 and use it to
generate a header file which declared macros to be used in the
definitions of the interface:
MIBVAR_ipForwarding(&ip_forwarding, _RW);
MIBVAR_INSTANCE_dot3StatsCollFrequencies(dot3_instantiate, _RO);
The entire collection of MIBs would be used to create a database of
name-to-oid and oid-to-description translations.
For the oid representation, what we have now works perfectly well and
avoids lots of unnecessary compaction; the extensible integers
business in BER and company doesn't serve any purpose for us. (I
think the biggest forest in the OID tree is under
iso.member-body.united-states, and those are still less than seven
digits.)
> 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...
In a lot of these cases, it makes more sense to create some sort of
configuration file which can be loaded by the boot loader. (In
particular, I'd like to see the IPFW goop compiled into a BPF program
and then loaded by the boot loader so that it is already configured
before interfaces are brought up. This would have saved a lot of pain
a year ago...)
> 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.
Which we already have through the magic of amd.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
wollman@lcs.mit.edu | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
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?199901111946.OAA15004>