Something like the Solaris xgettext(1) might
also be worth considering. It scan source
code looking for calls (or macro callouts),
extracts strings, and puts them in a file
ready for processing.

Seems like the tricky part is getting the info
into the sysctl(1) (or other) manpage. There are
plenty of reasonable ways to embed into source code.
Perhaps sysctl(1) could simply have an option that
pretty-prints a database of sysctl variable with
descriptions. The manual page could describe important,
stable variables, yet explain how to get a complete
list at any time.

Does /netbsd have sections that are not loaded into
memory? Like the symbol table, sysctl variable descriptions
and similar things could be kept in the /netbsd file
but not consume memory. It would help address keeping
the running system and the variable descriptions in sync.

	-gww

> -----Original Message-----
> From: tech-kern-owner@NetBSD.org [mailto:tech-kern-owner@NetBSD.org]On
> Behalf Of Hubert Feyrer
> Sent: Sunday, April 11, 2004 4:02 AM
> To: matthew green
> Cc: tech-kern@NetBSD.org
> Subject: Re: keeping sysctl documentation in sync.
> 
> 
> On Sun, 11 Apr 2004, matthew green wrote:
> > 	- cpp magic (not sure how this would work yet)
> > 	- something like the method aymeric posted: some structured
> > 	C comment above the sysctl create operation.
> > 	- put the docs in the kernel but in it's own unloaded section
> > 	and teach sysctl(8) to look in machdep.booted_kernel|/netbsd
> > 	(etc.) to find it.
> 
> Another way would be to put the documentation inside special commends in
> the source, and then extract them into a manpage, sort of what we do
> for the MAKEDEV.8 manpage (see src/share/man/man8/M*).
> 
> This won't solve the problem of old documentation if kernel is upgraded
> (e.g. when running a -current kernel on a -stable system) though.
> 
> 
>  - Hubert
> 
> -- 
> Hubert Feyrer <hubert@feyrer.de>
>