From owner-freebsd-current Mon Dec 8 16:40:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA04962 for current-outgoing; Mon, 8 Dec 1997 16:40:44 -0800 (PST) (envelope-from owner-freebsd-current) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA04919; Mon, 8 Dec 1997 16:40:20 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id AAA23174; Tue, 9 Dec 1997 00:40:16 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id BAA16299; Tue, 9 Dec 1997 01:39:41 +0100 (MET) Message-ID: <19971209013941.17444@follo.net> Date: Tue, 9 Dec 1997 01:39:41 +0100 From: Eivind Eklund To: Mike Smith Cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: VM system info References: <19971208093719.50393@follo.net> <199712090004.KAA02916@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <199712090004.KAA02916@word.smith.net.au>; from Mike Smith on Tue, Dec 09, 1997 at 10:34:26AM +1030 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Mike Smith] > [Eivind Eklund] >> [Mike Smith] >>> Would you buy it in /usr/share/misc/sysctl_nodes? I was thinking >>> about that when I saved John's message... >> >> If extracted from the kernel source, I'd say it was OK. > > Extracting from kernel source (at build time) is quite obviously > pointless. ? I'd say this give you a fairly recent snapshot of the available IOCTLs; I certainly update my kernel more often that my manpages (and much more often that /usr/share). I'd opt for it to be compiled as part of 'make world' instead, but there are certainly some good points to doing it at the kernel build tilme. > It's also not useful for parts of the tree that are dynamically > generated (although sysctl isn't actually too good at walking those > parts of the tree anyway). Ehm - what tree? The sysctl tree in the kernel? I'd guess we'd be able to find some way to document that in the source too, if we really wanted to. A single SYSCTL_DOC() macro could do it. >> However, if this is a file that developers are supposed to to keep >> up to date manually, I'm much more sceptical. Keeping >> documentation outside the source up to date has a tendency to be >> forgotten/ignored. > > This is the only way to do it; maintaining a document which describes a > superset of nodes. Even if it's incomplete (like scsi_modes) it would > be Better than Nothing. It might be better than nothing, but it is almost certainly going to wander far from the ultimate. Any form of documentation that is in-line in the code is much more likely to be kept up-to-date, and it _is_ fairly cheap. Any attempt at making things easier for the newcomers at a slight, indirect expense to the people 'in the know' seems to be shouted down immedately. Leanness of the kernel and the source tree seems to have a small but vocal minority that shout down any documentation that might actually be kept up to date. (Ref my attempt at finding some tolerable way to provide inline documentation for kernel file use last easter). Eivind.