Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Dec 1997 01:39:41 +0100
From:      Eivind Eklund <perhaps@yes.no>
To:        Mike Smith <mike@smith.net.au>
Cc:        dyson@FreeBSD.ORG, current@FreeBSD.ORG
Subject:   Re: VM system info
Message-ID:  <19971209013941.17444@follo.net>
In-Reply-To: <199712090004.KAA02916@word.smith.net.au>; from Mike Smith on Tue, Dec 09, 1997 at 10:34:26AM %2B1030
References:  <19971208093719.50393@follo.net> <199712090004.KAA02916@word.smith.net.au>

next in thread | previous in thread | raw e-mail | index | archive | help
[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.

<GENERAL RANT>
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).
</GENERAL>

Eivind.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971209013941.17444>