Date: Mon, 11 Jan 1999 07:44:28 -0500 (EST) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Nate Williams <nate@mt.sri.com> Cc: committers@FreeBSD.ORG Subject: Another approach... Re: sysctl descriptions Message-ID: <199901111244.HAA13985@khavrinen.lcs.mit.edu> In-Reply-To: <199901110452.VAA13815@mt.sri.com> References: <199901101807.KAA07319@dingo.cdrom.com> <199901102149.VAA00631@keep.lan.Awfulhak.org> <199901110452.VAA13815@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<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. (Before everyone gags, I'm not at all suggesting that we go the BER/DER/PER/FooER route for conveying the information; merely that we write an ASN.1 description of what the MIB is supposed to be and what the data types in it are.) This would require an ASN.1 interpreter in the base system, but what it gives us is the following: 1) An even-more-automated way of creating the code to define the things. 2) A specification against which the actual implementation can be checked. 3) Easy interface to SNMP. Things like the interface MIB can be directly expressed using the SNMP-defined MIB tree. 4) Machine-parseable documentation. Since we have already committed to including an SNMP agent in the base system RSN, we should end up with enough of an ASN.1 parser to do anything we need (with perhaps a bit of hacking). We already have an SNMP enterprise MIB arc which can be used to represent all our non-standardized features. -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?199901111244.HAA13985>