From owner-cvs-all Mon Jan 11 04:45:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA27999 for cvs-all-outgoing; Mon, 11 Jan 1999 04:45:04 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA27991 for ; Mon, 11 Jan 1999 04:45:02 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id HAA13985; Mon, 11 Jan 1999 07:44:28 -0500 (EST) (envelope-from wollman) Date: Mon, 11 Jan 1999 07:44:28 -0500 (EST) From: Garrett Wollman Message-Id: <199901111244.HAA13985@khavrinen.lcs.mit.edu> To: Nate Williams Cc: committers@FreeBSD.ORG Subject: Another approach... Re: sysctl descriptions 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> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk < 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