and any comment so marked must be in kernel-doc format. Do not use
"/**" to be begin a comment block unless the comment block contains
kernel-doc formatted comments. The closing comment marker for
-kernel-doc comments can be either "*/" or "**/".
+kernel-doc comments can be either "*/" or "**/", but "*/" is
+preferred in the Linux kernel tree.
Kernel-doc comments should be placed just before the function
or data structure being described.
* comment lines.
*
* The longer description can have multiple paragraphs.
- **/
+ */
-The first line, with the short description, must be on a single line.
+The short description following the subject can span multiple lines
+and ends with an @argument description, an empty line or the end of
+the comment block.
The @argument descriptions must begin on the very next line following
this opening short function description line, with no intervening
* perhaps with more lines and words.
*
* Longer description of this structure.
- **/
+ */
The kernel-doc function comments describe each parameter to the
function, in order, with the @name lines.
* (section header: (section description)? )*
(*)?*/
-The short function description ***cannot be multiline***, but the other
-descriptions can be (and they can contain blank lines). If you continue
-that initial short description onto a second line, that second line will
-appear further down at the beginning of the description section, which is
-almost certainly not what you had in mind.
+All "description" text can span multiple lines, although the
+function_name & its short description are traditionally on a single line.
+Description text may also contain blank lines (i.e., lines that contain
+only a "*").
+
+"section header:" names must be unique per function (or struct,
+union, typedef, enum).
Avoid putting a spurious blank line after the function name, or else the
description will be repeated!
Inside a struct description, you can use the "private:" and "public:"
comment tags. Structure fields that are inside a "private:" area
-are not listed in the generated output documentation.
+are not listed in the generated output documentation. The "private:"
+and "public:" tags must begin immediately following a "/*" comment
+marker. They may optionally include comments between the ":" and the
+ending "*/" marker.
Example:
struct my_struct {
int a;
int b;
-/* private: */
+/* private: internal use only */
int c;
};
+Including documentation blocks in source files
+----------------------------------------------
+
+To facilitate having source code and comments close together, you can
+include kernel-doc documentation blocks that are free-form comments
+instead of being kernel-doc for functions, structures, unions,
+enums, or typedefs. This could be used for something like a
+theory of operation for a driver or library code, for example.
+
+This is done by using a DOC: section keyword with a section title. E.g.:
+
+/**
+ * DOC: Theory of Operation
+ *
+ * The whizbang foobar is a dilly of a gizmo. It can do whatever you
+ * want it to do, at any time. It reads your mind. Here's how it works.
+ *
+ * foo bar splat
+ *
+ * The only drawback to this gizmo is that is can sometimes damage
+ * hardware, software, or its subject(s).
+ */
+
+DOC: sections are used in SGML templates files as indicated below.
+
+
How to make new SGML template files
-----------------------------------
!F<filename> <function [functions...]> is replaced by the
documentation, in <filename>, for the functions listed.
+!P<filename> <section title> is replaced by the contents of the DOC:
+section titled <section title> from <filename>.
+Spaces are allowed in <section title>; do not quote the <section title>.
Tim.
*/ <twaugh@redhat.com>
git://ftp.safe.ca / safe / jmp / linux-2.6 / blobdiff