cvs commit: src/sys/doc/subsys Dependencies Doxyfile-cam Doxyfile-crypto Doxyfile-dev_pci Doxyfile-dev_sound Doxyfile-dev_usb Doxyfile-geom Doxyfile-i4b Doxyfile-kern Doxyfile-libkern Doxyfile-linux Doxyfile-net80211 ...

Poul-Henning Kamp phk at
Fri May 26 14:17:25 PDT 2006

In message <20060526204457.3e545e4f at>, Alexander Leidinger writes:
>Quoting "Poul-Henning Kamp" <phk at> (Fri, 26 May 2006 20:20:36 +0200):
>> In message <200605261806.k4QI67D3007680 at>, Alexander Leiding
>> er writes:
>> >  This is the kernel subsystem API documentation generation framework.
>> >  
>> >  It uses doxygen to generate the API documentation. For each subsystem
>> >  a very small (about 20 lines with comments) subsystem specific Doxyfile
>> >  has to be written (have a look at the README for more). All common doxygen
>> >  options are specified in a separate file.
>> Now, this is all well and good, but the most critical question in
>> my mind is: how do we prevent (or alternatively: mark up) documentation
>> for functions which are not supposed to be public ?

Can we agree that no functions will be put into publicized documentation
until somebody has considered if the function actually is a public
function or not ?

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

More information about the cvs-src mailing list