|  | 
 | ================== | 
 | QEMU Documentation | 
 | ================== | 
 |  | 
 | QEMU's documentation is written in reStructuredText format and | 
 | built using the Sphinx documentation generator. We generate both | 
 | the HTML manual and the manpages from the some documentation sources. | 
 |  | 
 | hxtool and .hx files | 
 | -------------------- | 
 |  | 
 | The documentation for QEMU command line options and Human Monitor Protocol | 
 | (HMP) commands is written in files with the ``.hx`` suffix. These | 
 | are processed in two ways: | 
 |  | 
 |  * ``scripts/hxtool`` creates C header files from them, which are included | 
 |    in QEMU to do things like handle the ``--help`` option output | 
 |  * a Sphinx extension in ``docs/sphinx/hxtool.py`` generates rST output | 
 |    to be included in the HTML or manpage documentation | 
 |  | 
 | The syntax of these ``.hx`` files is simple. It is broadly an | 
 | alternation of C code put into the C output and rST format text | 
 | put into the documentation. A few special directives are recognised; | 
 | these are all-caps and must be at the beginning of the line. | 
 |  | 
 | ``HXCOMM`` is the comment marker. The line, including any arbitrary | 
 | text after the marker, is discarded and appears neither in the C output | 
 | nor the documentation output. | 
 |  | 
 | ``SRST`` starts a reStructuredText section. Following lines | 
 | are put into the documentation verbatim, and discarded from the C output. | 
 | The alternative form ``SRST()`` is used to define a label which can be | 
 | referenced from elsewhere in the rST documentation. The label will take | 
 | the form ``<DOCNAME-HXFILE-LABEL>``, where ``DOCNAME`` is the name of the | 
 | top level rST file, ``HXFILE`` is the filename of the .hx file without | 
 | the ``.hx`` extension, and ``LABEL`` is the text provided within the | 
 | ``SRST()`` directive. For example, | 
 | ``<system/invocation-qemu-options-initrd>``. | 
 |  | 
 | ``ERST`` ends the documentation section started with ``SRST``, | 
 | and switches back to a C code section. | 
 |  | 
 | ``DEFHEADING()`` defines a heading that should appear in both the | 
 | ``--help`` output and in the documentation. This directive should | 
 | be in the C code block. If there is a string inside the brackets, | 
 | this is the heading to use. If this string is empty, it produces | 
 | a blank line in the ``--help`` output and is ignored for the rST | 
 | output. | 
 |  | 
 | ``ARCHHEADING()`` is a variant of ``DEFHEADING()`` which produces | 
 | the heading only if the specified guest architecture was compiled | 
 | into QEMU. This should be avoided in new documentation. | 
 |  | 
 | Within C code sections, you should check the comments at the top | 
 | of the file to see what the expected usage is, because this | 
 | varies between files. For instance in ``qemu-options.hx`` we use | 
 | the ``DEF()`` macro to define each option and specify its ``--help`` | 
 | text, but in ``hmp-commands.hx`` the C code sections are elements | 
 | of an array of structs of type ``HMPCommand`` which define the | 
 | name, behaviour and help text for each monitor command. | 
 |  | 
 | In the file ``qemu-options.hx``, do not try to explicitly define a | 
 | reStructuredText label within a documentation section. This file | 
 | is included into two separate Sphinx documents, and some | 
 | versions of Sphinx will complain about the duplicate label | 
 | that results. Use the ``SRST()`` directive documented above, to | 
 | emit an unambiguous label. |