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]

In message <20060526204457.3e545e4f at Magellan.Leidinger.net>, Alexander Leidinger writes:
>Quoting "Poul-Henning Kamp" <phk at phk.freebsd.dk> (Fri, 26 May 2006 20:20:36 +0200):
>
>> In message <200605261806.k4QI67D3007680 at repoman.freebsd.org>, 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 ?
>
>http://www.stack.nl/~dimitri/doxygen/commands.html#cmdinternal

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.