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