diff options
Diffstat (limited to 'Documentation/doc-guide/kernel-doc.rst')
| -rw-r--r-- | Documentation/doc-guide/kernel-doc.rst | 476 |
1 files changed, 217 insertions, 259 deletions
diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst index 85efec8ecc44..2fb7f2bfc245 100644 --- a/Documentation/doc-guide/kernel-doc.rst +++ b/Documentation/doc-guide/kernel-doc.rst @@ -1,202 +1,48 @@ -Including kernel-doc comments -============================= - -The Linux kernel source files may contain structured documentation comments, or -kernel-doc comments to describe the functions and types and design of the -code. The documentation comments may be included to any of the reStructuredText -documents using a dedicated kernel-doc Sphinx directive extension. - -The kernel-doc directive is of the format:: - - .. kernel-doc:: source - :option: - -The *source* is the path to a source file, relative to the kernel source -tree. The following directive options are supported: - -export: *[source-pattern ...]* - Include documentation for all functions in *source* that have been exported - using ``EXPORT_SYMBOL`` or ``EXPORT_SYMBOL_GPL`` either in *source* or in any - of the files specified by *source-pattern*. - - The *source-pattern* is useful when the kernel-doc comments have been placed - in header files, while ``EXPORT_SYMBOL`` and ``EXPORT_SYMBOL_GPL`` are next to - the function definitions. - - Examples:: - - .. kernel-doc:: lib/bitmap.c - :export: - - .. kernel-doc:: include/net/mac80211.h - :export: net/mac80211/*.c - -internal: *[source-pattern ...]* - Include documentation for all functions and types in *source* that have - **not** been exported using ``EXPORT_SYMBOL`` or ``EXPORT_SYMBOL_GPL`` either - in *source* or in any of the files specified by *source-pattern*. - - Example:: - - .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c - :internal: - -doc: *title* - Include documentation for the ``DOC:`` paragraph identified by *title* in - *source*. Spaces are allowed in *title*; do not quote the *title*. The *title* - is only used as an identifier for the paragraph, and is not included in the - output. Please make sure to have an appropriate heading in the enclosing - reStructuredText document. - - Example:: - - .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c - :doc: High Definition Audio over HDMI and Display Port - -functions: *function* *[...]* - Include documentation for each *function* in *source*. - - Example:: - - .. kernel-doc:: lib/bitmap.c - :functions: bitmap_parselist bitmap_parselist_user - -Without options, the kernel-doc directive includes all documentation comments -from the source file. - -The kernel-doc extension is included in the kernel source tree, at -``Documentation/sphinx/kerneldoc.py``. Internally, it uses the -``scripts/kernel-doc`` script to extract the documentation comments from the -source. - -.. _kernel_doc: - Writing kernel-doc comments =========================== -In order to provide embedded, "C" friendly, easy to maintain, but consistent and -extractable overview, function and type documentation, the Linux kernel has -adopted a consistent style for documentation comments. The format for this -documentation is called the kernel-doc format, described below. This style -embeds the documentation within the source files, using a few simple conventions -for adding documentation paragraphs and documenting functions and their -parameters, structures and unions and their members, enumerations, and typedefs. - -.. note:: The kernel-doc format is deceptively similar to gtk-doc or Doxygen, - yet distinctively different, for historical reasons. The kernel source - contains tens of thousands of kernel-doc comments. Please stick to the style - described here. - -The ``scripts/kernel-doc`` script is used by the Sphinx kernel-doc extension in -the documentation build to extract this embedded documentation into the various -HTML, PDF, and other format documents. - -In order to provide good documentation of kernel functions and data structures, -please use the following conventions to format your kernel-doc comments in the -Linux kernel source. - -How to format kernel-doc comments ---------------------------------- +The Linux kernel source files may contain structured documentation +comments in the kernel-doc format to describe the functions, types +and design of the code. It is easier to keep documentation up-to-date +when it is embedded in source files. -The opening comment mark ``/**`` is reserved for kernel-doc comments. Only -comments so marked will be considered by the ``kernel-doc`` tool. Use it only -for comment blocks that contain kernel-doc formatted comments. The usual ``*/`` -should be used as the closing comment marker. The lines in between should be -prefixed by `` * `` (space star space). +.. note:: The kernel-doc format is deceptively similar to javadoc, + gtk-doc or Doxygen, yet distinctively different, for historical + reasons. The kernel source contains tens of thousands of kernel-doc + comments. Please stick to the style described here. -The function and type kernel-doc comments should be placed just before the -function or type being described. The overview kernel-doc comments may be freely -placed at the top indentation level. - -Example kernel-doc function comment:: - - /** - * foobar() - Brief description of foobar. - * @argument1: Description of parameter argument1 of foobar. - * @argument2: Description of parameter argument2 of foobar. - * - * Longer description of foobar. - * - * Context: Interrupt / locking context of foobar. - * Return: Description of return value of foobar. - */ - int foobar(int argument1, char *argument2) - -The format is similar for documentation for structures, enums, paragraphs, -etc. See the sections below for specific details of each type. - -The kernel-doc structure is extracted from the comments, and proper `Sphinx C -Domain`_ function and type descriptions with anchors are generated for them. The -descriptions are filtered for special kernel-doc highlights and -cross-references. See below for details. +The kernel-doc structure is extracted from the comments, and proper +`Sphinx C Domain`_ function and type descriptions with anchors are +generated from them. The descriptions are filtered for special kernel-doc +highlights and cross-references. See below for details. .. _Sphinx C Domain: http://www.sphinx-doc.org/en/stable/domains.html +Every function that is exported to loadable modules using +``EXPORT_SYMBOL`` or ``EXPORT_SYMBOL_GPL`` should have a kernel-doc +comment. Functions and data structures in header files which are intended +to be used by modules should also have kernel-doc comments. -Parameters and member arguments -------------------------------- - -The kernel-doc function comments describe each parameter to the function and -function typedefs or each member of struct/union, in order, with the -``@argument:`` descriptions. For each non-private member argument, one -``@argument`` definition is needed. - -The ``@argument:`` descriptions begin on the very next line following -the opening brief function description line, with no intervening blank -comment lines. - -The ``@argument:`` descriptions may span multiple lines. - -.. note:: - - If the ``@argument`` description has multiple lines, the continuation - of the description should be starting exactly at the same column as - the previous line, e. g.:: - - * @argument: some long description - * that continues on next lines - - or:: - - * @argument: - * some long description - * that continues on next lines - -If a function or typedef parameter argument is ``...`` (e. g. a variable -number of arguments), its description should be listed in kernel-doc -notation as:: - - * @...: description - -Private members -~~~~~~~~~~~~~~~ +It is good practice to also provide kernel-doc formatted documentation +for functions externally visible to other kernel files (not marked +``static``). We also recommend providing kernel-doc formatted +documentation for private (file ``static``) routines, for consistency of +kernel source code layout. This is lower priority and at the discretion +of the maintainer of that kernel source file. -Inside a struct or union 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. +How to format kernel-doc comments +--------------------------------- -The ``private:`` and ``public:`` tags must begin immediately following a -``/*`` comment marker. They may optionally include comments between the -``:`` and the ending ``*/`` marker. +The opening comment mark ``/**`` is used for kernel-doc comments. The +``kernel-doc`` tool will extract comments marked this way. The rest of +the comment is formatted like a normal multi-line comment with a column +of asterisks on the left side, closing with ``*/`` on a line by itself. -Example:: - - /** - * struct my_struct - short description - * @a: first member - * @b: second member - * @d: fourth member - * - * Longer description - */ - struct my_struct { - int a; - int b; - /* private: internal use only */ - int c; - /* public: the next one is public */ - int d; - }; +The function and type kernel-doc comments should be placed just before +the function or type being described in order to maximise the chance +that somebody changing the code will also change the documentation. The +overview kernel-doc comments may be placed anywhere at the top indentation +level. Function documentation ---------------------- @@ -230,6 +76,34 @@ The brief description following the function name may span multiple lines, and ends with an argument description, a blank comment line, or the end of the comment block. +Function parameters +~~~~~~~~~~~~~~~~~~~ + +Each function argument should be described in order, immediately following +the short function description. Do not leave a blank line between the +function description and the arguments, nor between the arguments. + +Each ``@argument:`` description may span multiple lines. + +.. note:: + + If the ``@argument`` description has multiple lines, the continuation + of the description should start at the same column as the previous line:: + + * @argument: some long description + * that continues on next lines + + or:: + + * @argument: + * some long description + * that continues on next lines + +If a function has a variable number of arguments, its description should +be written in kernel-doc notation as:: + + * @...: description + Function context ~~~~~~~~~~~~~~~~ @@ -287,57 +161,119 @@ The general format of a struct, union, and enum kernel-doc comment is:: /** * struct struct_name - Brief description. - * @argument: Description of member member_name. + * @member1: Description of member1. + * @member2: Description of member2. + * One can provide multiple line descriptions + * for members. * * Description of the structure. */ -On the above, ``struct`` is used to mean structs. You can also use ``union`` -and ``enum`` to describe unions and enums. ``argument`` is used -to mean struct and union member names as well as enumerations in an enum. +You can replace the ``struct`` in the above example with ``union`` or +``enum`` to describe unions or enums. ``member`` is used to mean struct +and union member names as well as enumerations in an enum. -The brief description following the structure name may span multiple lines, and -ends with a member description, a blank comment line, or the end of the -comment block. +The brief description following the structure name may span multiple +lines, and ends with a member description, a blank comment line, or the +end of the comment block. + +Members +~~~~~~~ -The kernel-doc data structure comments describe each member of the structure, -in order, with the member descriptions. +Members of structs, unions and enums should be documented the same way +as function parameters; they immediately succeed the short description +and may be multi-line. + +Inside a struct or union 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. + +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 - short description + * @a: first member + * @b: second member + * @d: fourth member + * + * Longer description + */ + struct my_struct { + int a; + int b; + /* private: internal use only */ + int c; + /* public: the next one is public */ + int d; + }; + +In-line member documentation comments +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The structure members may also be documented in-line within the definition. +There are two styles, single-line comments where both the opening ``/**`` and +closing ``*/`` are on the same line, and multi-line comments where they are each +on a line of their own, like all other kernel-doc comments:: + + /** + * struct foo - Brief description. + * @foo: The Foo member. + */ + struct foo { + int foo; + /** + * @bar: The Bar member. + */ + int bar; + /** + * @baz: The Baz member. + * + * Here, the member description may contain several paragraphs. + */ + int baz; + /** @foobar: Single line description. */ + int foobar; + } Nested structs/unions ~~~~~~~~~~~~~~~~~~~~~ -It is possible to document nested structs unions, like:: +It is possible to document nested structs and unions, like:: /** * struct nested_foobar - a struct with nested unions and structs - * @arg1: - first argument of anonymous union/anonymous struct - * @arg2: - second argument of anonymous union/anonymous struct - * @arg3: - third argument of anonymous union/anonymous struct - * @arg4: - fourth argument of anonymous union/anonymous struct - * @bar.st1.arg1 - first argument of struct st1 on union bar - * @bar.st1.arg2 - second argument of struct st1 on union bar - * @bar.st2.arg1 - first argument of struct st2 on union bar - * @bar.st2.arg2 - second argument of struct st2 on union bar + * @memb1: first member of anonymous union/anonymous struct + * @memb2: second member of anonymous union/anonymous struct + * @memb3: third member of anonymous union/anonymous struct + * @memb4: fourth member of anonymous union/anonymous struct + * @bar.st1.memb1: first member of struct st1 on union bar + * @bar.st1.memb2: second member of struct st1 on union bar + * @bar.st2.memb1: first member of struct st2 on union bar + * @bar.st2.memb2: second member of struct st2 on union bar struct nested_foobar { /* Anonymous union/struct*/ union { struct { - int arg1; - int arg2; + int memb1; + int memb2; } struct { - void *arg3; - int arg4; + void *memb3; + int memb4; } } union { struct { - int arg1; - int arg2; + int memb1; + int memb2; } st1; struct { - void *arg1; - int arg2; + void *memb1; + int memb2; } st2; } bar; }; @@ -345,9 +281,9 @@ It is possible to document nested structs unions, like:: .. note:: #) When documenting nested structs or unions, if the struct/union ``foo`` - is named, the argument ``bar`` inside it should be documented as + is named, the member ``bar`` inside it should be documented as ``@foo.bar:`` - #) When the nested struct/union is anonymous, the argument ``bar`` on it + #) When the nested struct/union is anonymous, the member ``bar`` in it should be documented as ``@bar:`` Typedef documentation @@ -375,7 +311,6 @@ Typedefs with function prototypes can also be documented:: */ typedef void (*type_name)(struct v4l2_ctrl *arg1, void *arg2); - Highlights and cross-references ------------------------------- @@ -447,37 +382,6 @@ cross-references. For further details, please refer to the `Sphinx C Domain`_ documentation. - - -In-line member documentation comments -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The structure members may also be documented in-line within the definition. -There are two styles, single-line comments where both the opening ``/**`` and -closing ``*/`` are on the same line, and multi-line comments where they are each -on a line of their own, like all other kernel-doc comments:: - - /** - * struct foo - Brief description. - * @foo: The Foo member. - */ - struct foo { - int foo; - /** - * @bar: The Bar member. - */ - int bar; - /** - * @baz: The Baz member. - * - * Here, the member description may contain several paragraphs. - */ - int baz; - /** @foobar: Single line description. */ - int foobar; - } - - Overview documentation comments ------------------------------- @@ -507,22 +411,76 @@ The title following ``DOC:`` acts as a heading within the source file, but also as an identifier for extracting the documentation comment. Thus, the title must be unique within the file. -Recommendations ---------------- +Including kernel-doc comments +============================= + +The documentation comments may be included in any of the reStructuredText +documents using a dedicated kernel-doc Sphinx directive extension. + +The kernel-doc directive is of the format:: + + .. kernel-doc:: source + :option: + +The *source* is the path to a source file, relative to the kernel source +tree. The following directive options are supported: -We definitely need kernel-doc formatted documentation for functions that are -exported to loadable modules using ``EXPORT_SYMBOL`` or ``EXPORT_SYMBOL_GPL``. +export: *[source-pattern ...]* + Include documentation for all functions in *source* that have been exported + using ``EXPORT_SYMBOL`` or ``EXPORT_SYMBOL_GPL`` either in *source* or in any + of the files specified by *source-pattern*. -We also look to provide kernel-doc formatted documentation for functions -externally visible to other kernel files (not marked "static"). + The *source-pattern* is useful when the kernel-doc comments have been placed + in header files, while ``EXPORT_SYMBOL`` and ``EXPORT_SYMBOL_GPL`` are next to + the function definitions. -We also recommend providing kernel-doc formatted documentation for private (file -"static") routines, for consistency of kernel source code layout. But this is -lower priority and at the discretion of the MAINTAINER of that kernel source -file. + Examples:: -Data structures visible in kernel include files should also be documented using -kernel-doc formatted comments. + .. kernel-doc:: lib/bitmap.c + :export: + + .. kernel-doc:: include/net/mac80211.h + :export: net/mac80211/*.c + +internal: *[source-pattern ...]* + Include documentation for all functions and types in *source* that have + **not** been exported using ``EXPORT_SYMBOL`` or ``EXPORT_SYMBOL_GPL`` either + in *source* or in any of the files specified by *source-pattern*. + + Example:: + + .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c + :internal: + +doc: *title* + Include documentation for the ``DOC:`` paragraph identified by *title* in + *source*. Spaces are allowed in *title*; do not quote the *title*. The *title* + is only used as an identifier for the paragraph, and is not included in the + output. Please make sure to have an appropriate heading in the enclosing + reStructuredText document. + + Example:: + + .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c + :doc: High Definition Audio over HDMI and Display Port + +functions: *function* *[...]* + Include documentation for each *function* in *source*. + + Example:: + + .. kernel-doc:: lib/bitmap.c + :functions: bitmap_parselist bitmap_parselist_user + +Without options, the kernel-doc directive includes all documentation comments +from the source file. + +The kernel-doc extension is included in the kernel source tree, at +``Documentation/sphinx/kerneldoc.py``. Internally, it uses the +``scripts/kernel-doc`` script to extract the documentation comments from the +source. + +.. _kernel_doc: How to use kernel-doc to generate man pages ------------------------------------------- |