aboutsummaryrefslogtreecommitdiff
path: root/docs/devel/docs.rst
AgeCommit message (Collapse)AuthorFilesLines
2024-02-20docs: correct typosManos Pitsidianakis1-1/+1
Correct typos automatically found with the `typos` tool <https://crates.io/crates/typos> Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> (mjt: trivial fixup) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-02doc/sphinx/hxtool.py: add optional label argument to SRST directiveDavid Woodhouse1-2/+10
We can't just embed labels directly into files like qemu-options.hx which are included from multiple top-level rST files, because Sphinx sees the labels as duplicate: https://github.com/sphinx-doc/sphinx/issues/9707 So add an optional argument to the SRST directive which causes a label of the form '.. _DOCNAME-HXFILE-LABEL:' to be emitted, where 'DOCNAME' is the name of the top level rST file, 'HXFILE' is the filename of the .hx file, and 'LABEL' is the text provided within the 'SRST()' directive. Using the DOCNAME of the top-level rST document means that it is unique even when the .hx file is included from two different documents, as is the case for qemu-options.hx Now where the Xen PV documentation refers to the documentation for the -initrd command line option, it can emit a link directly to it as '<system/invocation-qemu-options-initrd>'. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20240130190348.682912-1-dwmw2@infradead.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-15docs/devel/docs: Document .hx file syntaxPeter Maydell1-0/+60
We don't currently document the syntax of .hx files anywhere except in a few comments at the top of individual .hx files. We don't even have somewhere in the developer docs where we could do this. Add a new files docs/devel/docs.rst which can be a place to document how our docs build process works. For the moment, put in only a brief introductory paragraph and the documentation of the .hx files. We could later add to this file by for example describing how the QAPI-schema-to-docs process works, or anything else that developers might need to know about how to add documentation. Make the .hx files refer to this doc file, and clean up their header comments to be more accurate for the usage in each file and less cut-n-pasted. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Luc Michel <luc.michel@amd.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Message-id: 20231212162313.1742462-1-peter.maydell@linaro.org