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 ...

[M. Warner Losh]

In message: <20060528214157.71671d52 at Magellan.Leidinger.net>
            Alexander Leidinger <netchild at FreeBSD.org> writes:
: Quoting "M. Warner Losh" <imp at bsdimp.com> (Sun, 28 May 2006 13:12:12 -0600 (MDT)):
: 
: > In message: <20060528123915.7fe8e278 at Magellan.Leidinger.net>
: >             Alexander Leidinger <netchild at freebsd.org> writes:
: > : But when we have marked the internal functions as such, we can also
: > : generate an official version without the internal functions. It's just
: > : a switch. But so far I think we need to include everything until a
: > : subsystem is fully documented.
: > 
: > I think we should document everything and mark the *EXTERNAL*
: > functions as such.  I agree with your commentary about having full
: > kernel docs, and approved API subset as well.  However, kernel
: > functions are by default internal unless we deside otherwise.
: 
: We can make this a 3-tier document. We can mark some functions as
: @internal, some without any special markup (they are public then), and
: some with some special comments/notes/whatever (we have to invent
: something).
:
: The functions marked as @internal are only for the use in the subsystem
: itself (maybe together with any other documented constraint). The
: functions without any special markup can be used in other subsystems of
: the kernel. And finally the special marked functions -- let's call them
: EXTERNAL -- can be used by 3rd party developers.
: 
: How does this sound?

One area where we have had problems in the past is when the 2nd tier
of functions changes.  Many interfaces that the designer had intended
to be private were used inappropriately elsewhere in the kernel.  We
have issues with this in vinum, many of the file system drivers, many
of the tty drivers, etc.  Of course, there used to be almost no
documentation at all, so people just used what seemed right, despite
the original author's intentions.  Usually these sub-systems have well
defined interfaces to each other, and other sub-systems calling in is
a bad thing.  Ditto with the driver <-> driver abstraction layers
(tty, sound, etc).  They should be using only what you call the
external interfaces and nothing else.  So I'm not sure how well your
proposal maps to our current needs.

: > : Since we have no API docs, everyone has to have a look at the kernel on
: > : his own. This only provides a little bit of help here.
: > 
: > We have api docs.  Please don't say that we have none.  There's a
: > bunch of documentation in the man9 section of the man page.  Sure, it
: > is incomplete, misleading and obsolete in places, but it is
: > documentation.
: 
: Sorry... there are docs which document the API, I agree. But we don't
: really have well known API documentation (as in high level overview,
: what fits together how, and such). You have to know what you want to
: do, then you can make use of plenty of docs. But if you don't know what
: you are searching, it's not easy (maybe more easy as in linux, I don't
: know, but not as easy as it could be).

Again, between the handbook and the man pages we have this.  It needs
a lot of work, but we do have it.  It shows what to do at a very
rudamentary level, but you can find what you want.

I'm not sure you'll ever find the high level overview in the sources.
There's rarely a good place for it, and it changes with time.

Warner