parse-headers.rst 4.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187
  1. ===========================
  2. Including uAPI header files
  3. ===========================
  4. Sometimes, it is useful to include header files and C example codes in
  5. order to describe the userspace API and to generate cross-references
  6. between the code and the documentation. Adding cross-references for
  7. userspace API files has an additional advantage: Sphinx will generate warnings
  8. if a symbol is not found at the documentation. That helps to keep the
  9. uAPI documentation in sync with the Kernel changes.
  10. The :ref:`parse_headers.py <parse_headers>` provides a way to generate such
  11. cross-references. It has to be called via Makefile, while building the
  12. documentation. Please see ``Documentation/userspace-api/media/Makefile`` for an example
  13. about how to use it inside the Kernel tree.
  14. .. _parse_headers:
  15. tools/docs/parse_headers.py
  16. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  17. NAME
  18. ****
  19. parse_headers.py - parse a C file, in order to identify functions, structs,
  20. enums and defines and create cross-references to a Sphinx book.
  21. USAGE
  22. *****
  23. parse-headers.py [-h] [-d] [-t] ``FILE_IN`` ``FILE_OUT`` ``FILE_RULES``
  24. SYNOPSIS
  25. ********
  26. Converts a C header or source file ``FILE_IN`` into a ReStructured Text
  27. included via ..parsed-literal block with cross-references for the
  28. documentation files that describe the API. It accepts an optional
  29. ``FILE_RULES`` file to describe what elements will be either ignored or
  30. be pointed to a non-default reference type/name.
  31. The output is written at ``FILE_OUT``.
  32. It is capable of identifying ``define``, ``struct``, ``typedef``, ``enum``
  33. and enum ``symbol``, creating cross-references for all of them.
  34. It is also capable of distinguishing ``#define`` used for specifying
  35. Linux-specific macros used to define ``ioctl``.
  36. The optional ``FILE_RULES`` contains a set of rules like::
  37. ignore ioctl VIDIOC_ENUM_FMT
  38. replace ioctl VIDIOC_DQBUF vidioc_qbuf
  39. replace define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ :c:type:`v4l2_event_motion_det`
  40. POSITIONAL ARGUMENTS
  41. ********************
  42. ``FILE_IN``
  43. Input C file
  44. ``FILE_OUT``
  45. Output RST file
  46. ``FILE_RULES``
  47. Exceptions file (optional)
  48. OPTIONS
  49. *******
  50. ``-h``, ``--help``
  51. show a help message and exit
  52. ``-d``, ``--debug``
  53. Increase debug level. Can be used multiple times
  54. ``-t``, ``--toc``
  55. instead of a literal block, outputs a TOC table at the RST file
  56. DESCRIPTION
  57. ***********
  58. Creates an enriched version of a Kernel header file with cross-links
  59. to each C data structure type, from ``FILE_IN``, formatting it with
  60. reStructuredText notation, either as-is or as a table of contents.
  61. It accepts an optional ``FILE_RULES`` which describes what elements will be
  62. either ignored or be pointed to a non-default reference, and optionally
  63. defines the C namespace to be used.
  64. It is meant to allow having more comprehensive documentation, where
  65. uAPI headers will create cross-reference links to the code.
  66. The output is written at the ``FILE_OUT``.
  67. The ``FILE_RULES`` may contain contain three types of statements:
  68. **ignore**, **replace** and **namespace**.
  69. By default, it create rules for all symbols and defines, but it also
  70. allows parsing an exception file. Such file contains a set of rules
  71. using the syntax below:
  72. 1. Ignore rules:
  73. ignore *type* *symbol*
  74. Removes the symbol from reference generation.
  75. 2. Replace rules:
  76. replace *type* *old_symbol* *new_reference*
  77. Replaces *old_symbol* with a *new_reference*.
  78. The *new_reference* can be:
  79. - A simple symbol name;
  80. - A full Sphinx reference.
  81. 3. Namespace rules
  82. namespace *namespace*
  83. Sets C *namespace* to be used during cross-reference generation. Can
  84. be overridden by replace rules.
  85. On ignore and replace rules, *type* can be:
  86. - ioctl:
  87. for defines of the form ``_IO*``, e.g., ioctl definitions
  88. - define:
  89. for other defines
  90. - symbol:
  91. for symbols defined within enums;
  92. - typedef:
  93. for typedefs;
  94. - enum:
  95. for the name of a non-anonymous enum;
  96. - struct:
  97. for structs.
  98. EXAMPLES
  99. ********
  100. - Ignore a define ``_VIDEODEV2_H`` at ``FILE_IN``::
  101. ignore define _VIDEODEV2_H
  102. - On an data structure like this enum::
  103. enum foo { BAR1, BAR2, PRIVATE };
  104. It won't generate cross-references for ``PRIVATE``::
  105. ignore symbol PRIVATE
  106. At the same struct, instead of creating one cross reference per symbol,
  107. make them all point to the ``enum foo`` C type::
  108. replace symbol BAR1 :c:type:\`foo\`
  109. replace symbol BAR2 :c:type:\`foo\`
  110. - Use C namespace ``MC`` for all symbols at ``FILE_IN``::
  111. namespace MC
  112. BUGS
  113. ****
  114. Report bugs to Mauro Carvalho Chehab <mchehab@kernel.org>
  115. COPYRIGHT
  116. *********
  117. Copyright (c) 2016, 2025 by Mauro Carvalho Chehab <mchehab+huawei@kernel.org>.
  118. License GPLv2: GNU GPL version 2 <https://gnu.org/licenses/gpl.html>.
  119. This is free software: you are free to change and redistribute it.
  120. There is NO WARRANTY, to the extent permitted by law.