diff options
| author | Peter Maydell <peter.maydell@linaro.org> | 2020-02-06 11:59:00 +0000 |
|---|---|---|
| committer | Peter Maydell <peter.maydell@linaro.org> | 2020-03-06 17:23:32 +0000 |
| commit | 77416266a167edd18813e7cd80426bf200abb6dd (patch) | |
| tree | 00aa30f03c0bd6df708104d220a6162dc760fdd1 | |
| parent | 50bb37e87f729300fd4d3f9f379c634da69bece2 (diff) | |
qapi/qapi-schema.json: Put headers in their own doc-comment blocks
Our current QAPI doc-comment markup allows section headers
(introduced with a leading '=' or '==') anywhere in any documentation
comment. This works for texinfo because the texi generator simply
prints a texinfo heading directive at that point in the output
stream. For rST generation, since we're assembling a tree of
docutils nodes, this is awkward because a new section implies
starting a new section node at the top level of the tree and
generating text into there.
New section headings in the middle of the documentation of a command
or event would be pretty nonsensical, and in fact we only ever output
new headings using 'freeform' doc comment blocks whose only content
is the single line of the heading, with two exceptions, which are in
the introductory freeform-doc-block at the top of
qapi/qapi-schema.json.
Split that doc-comment up so that the heading lines are in their own
doc-comment. This will allow us to tighten the specification to
insist that heading lines are always standalone, rather than
requiring the rST document generator to look at every line in a doc
comment block and handle headings in odd places.
This change makes no difference to the generated texi.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| -rw-r--r-- | qapi/qapi-schema.json | 12 |
1 files changed, 9 insertions, 3 deletions
diff --git a/qapi/qapi-schema.json b/qapi/qapi-schema.json index fe980ce437..ff5aea5945 100644 --- a/qapi/qapi-schema.json +++ b/qapi/qapi-schema.json @@ -1,7 +1,9 @@ # -*- Mode: Python -*- ## # = Introduction -# +## + +## # This document describes all commands currently supported by QMP. # # Most of the time their usage is exactly the same as in the user Monitor, this @@ -25,9 +27,13 @@ # # Please, refer to the QMP specification (docs/interop/qmp-spec.txt) for # detailed information on the Server command and response formats. -# +## + +## # = Stability Considerations -# +## + +## # The current QMP command set (described in this file) may be useful for a # number of use cases, however it's limited and several commands have bad # defined semantics, specially with regard to command completion. |