Revision tags: v10.0.0, v9.2.3 |
|
#
9beccc2d |
| 16-Mar-2025 |
Stefan Hajnoczi <stefanha@redhat.com> |
Merge tag 'pull-qapi-2025-03-14' of https://repo.or.cz/qemu/armbru into staging
QAPI patches patches for 2025-03-14
# -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEENUvIs9frKmtoZ05fOHC0AOuRhlMFA
Merge tag 'pull-qapi-2025-03-14' of https://repo.or.cz/qemu/armbru into staging
QAPI patches patches for 2025-03-14
# -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEENUvIs9frKmtoZ05fOHC0AOuRhlMFAmfT/U0SHGFybWJydUBy # ZWRoYXQuY29tAAoJEDhwtADrkYZThb4P/i2FNedYYeU+qOAtjKwCE0bnbtxWdthj # Zd+0u0LOXxkK7+nqgva+2+Szl4Ee0rYrbwVjd26nYRtB/m1/q1Glj1GTTAO+Xzpb # 3q4/ByFTDG3/mFktfVkE5HAJ7RGbjI3toRFWbpw1C4RabkX+dyZZ0MVwkfBwiyY7 # bEW7cW9OZlIXbMS867n7gURqEsD+LWXzxX5ozeWZGQVTp5nbQdubulYTkxJTXK+A # as2Q+RJhfB2lVJHAY3xN6R+gjHUNCBfwzfSFGMTMr+tYPeHZVssWeypXJJ9Qh7aA # dVLfVCY6PbstrGD1dGybIY1HfUTjJQNiyZ3qIoRfkxsfZcO7ru6Q5CMfEgxwcu53 # FaXLB3ra3R5cmYKFVeasEKHo/xsXeb3MAKCGLLqp7gC2GGdGvZAyHJevFZJslC+Q # /AbGtbmNYOYCkJdbT3r8bu9Qc7p2llw24Pjw/9I/qvwkKy3xdDyZQS+lT/vyYZvS # zc/hnlJR8UQvGXtzf0OrNCf8lDswNP6r51eTpno0OCQatrDi0ZjZqIOxHUUOn1pr # AE4JRDjtDoOqw8ltZxrulsiySSHewM4ouS3MXylpMk1PoWNq/6v8nUYL7p2RGgMq # FKyEdInExe1dWEjwaqPABBHdAWpZbmH0wmRLgeFaDvgmqqrOqFFeBKbgLFC2xcX5 # pgR35cz28GUh # =0HX3 # -----END PGP SIGNATURE----- # gpg: Signature made Fri 14 Mar 2025 05:56:29 EDT # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653
* tag 'pull-qapi-2025-03-14' of https://repo.or.cz/qemu/armbru: docs: enable transmogrifier for QSD and QGA docs: disambiguate references in qapi-domain.rst docs: add QAPI namespace "QMP" to qemu-qmp-ref docs/qapi-domain: add namespaced index support docs/qapi_domain: add namespace support to cross-references docs/qapidoc: add :namespace: option to qapi-doc directive docs/qapi-domain: add qapi:namespace directive docs/qapi-domain: add :namespace: override option docs/qapi_domain: add namespace support to FQN docs/qapi-domain: always store fully qualified name in signode docs/qapi_domain: isolate TYPE_CHECKING imports qapi/block-core: Improve x-blockdev-change documentation
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
show more ...
|
#
25d44f57 |
| 12-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add namespaced index support
Generate an index-per-namespace for the QAPI domain. Due to a limitation with Sphinx's architecture, these indices must be defined during setup time an
docs/qapi-domain: add namespaced index support
Generate an index-per-namespace for the QAPI domain. Due to a limitation with Sphinx's architecture, these indices must be defined during setup time and cannot be dynamically created on-demand when a namespace directive is encountered.
Owing to that limitation, add a configuration value to conf.py that specifies which QAPI namespaces we'll generate indices for.
Indices will be named after their namespace, e.g. the "QMP" namespace will generate to "qapi-qmp-index.html" and can be referenced using `qapi-qmp-index`.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250313044312.189276-9-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
7127e14f |
| 12-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi_domain: add namespace support to cross-references
This patch does three things:
1. Record the current namespace context in pending_xrefs so it can be used for link resolution later, 2.
docs/qapi_domain: add namespace support to cross-references
This patch does three things:
1. Record the current namespace context in pending_xrefs so it can be used for link resolution later, 2. Pass that recorded namespace context to find_obj() when resolving a reference, and 3. Wildly and completely rewrite find_obj().
cross-reference support is expanded to tolerate the presence or absence of either namespace or module, and to cope with the presence or absence of contextual information for either.
References now work like this:
1. If the explicit reference target is recorded in the domain's object registry, we link to that target and stop looking. We do this lookup regardless of how fully qualified the target is, which allows direct references to modules (which don't have a module component to their names) or direct references to definitions that may or may not belong to a namespace or module.
2. If contextual information is available from qapi:namespace or qapi:module directives, try using those components to find a direct match to the implied target name.
3. If both prior lookups fail, generate a series of regular expressions looking for wildcard matches in order from most to least specific. Any explicitly provided components (namespace, module) *must* match exactly, but both contextual and entirely omitted components are allowed to differ from the search result. Note that if more than one result is found, Sphinx will emit a warning (a build error for QEMU) and list all of the candidate references.
The practical upshot is that in the large majority of cases, namespace and module information is not required when creating simple `references` to definitions from within the same context -- even when identical definitions exist in other contexts.
Even when using simple `references` from elsewhere in the QEMU documentation manual, explicit namespace info is not required if there is only one definition by that name.
Disambiguation *will* be required from outside of the QAPI documentation when referencing e.g. block-core definitions, which are shared between QEMU QMP and the QEMU Storage Daemon. In that case, there are two options:
A: References can be made partially or fully explicit, e.g. `QMP:block-dirty-bitmap-add` will link to the QEMU version of the definition, while `QSD:block-dirty-bitmap-add` would link to the QSD version.
B: If all of the references in a document are intended to go to the same place, you can insert a "qapi:namespace:: QMP" directive to influence the fuzzy-searching for later references.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250313044312.189276-8-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> [Commit message typo fixed] Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
7c7247b2 |
| 12-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add qapi:namespace directive
Add a new directive that marks the beginning of a QAPI "namespace", for example; "QMP", "QGA" or "QSD". This directive will associate all subsequent QA
docs/qapi-domain: add qapi:namespace directive
Add a new directive that marks the beginning of a QAPI "namespace", for example; "QMP", "QGA" or "QSD". This directive will associate all subsequent QAPI directives in a document with the specified namespace. This does not change the visual display of any of the definitions or index entries, but does change the "Fully Qualified Name" inside the QAPI domain's object table. This allows for two different "namespaces" to define entities with otherwise identical names -- which will come in handy for documenting both QEMU QMP and the QEMU Storage Daemon.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250313044312.189276-6-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
9ca404f0 |
| 12-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add :namespace: override option
Akin to the :module: override option, the :namespace: options allows you to forcibly override the contextual namespace associatied with a definition
docs/qapi-domain: add :namespace: override option
Akin to the :module: override option, the :namespace: options allows you to forcibly override the contextual namespace associatied with a definition.
We don't necessarily actually need this, but I felt compelled to stick close to how the Python domain works that offers context overrides.
As of this commit, it is possible to add e.g. ":namespace: QMP" to any QAPI directive to forcibly associate that definition with a given namespace.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250313044312.189276-5-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
74d40b01 |
| 12-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi_domain: add namespace support to FQN
This patch adds a namespace component to the "Fully Qualified Name", in the form of "domain:module.name". As there are no namespace directives or optio
docs/qapi_domain: add namespace support to FQN
This patch adds a namespace component to the "Fully Qualified Name", in the form of "domain:module.name". As there are no namespace directives or options yet, this component will simply be empty as of this patch.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250313044312.189276-4-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
e36afc7b |
| 12-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: always store fully qualified name in signode
Currently, only the definition name is stored in the tree metadata; but the node property is confusingly called "fullname". Rectify thi
docs/qapi-domain: always store fully qualified name in signode
Currently, only the definition name is stored in the tree metadata; but the node property is confusingly called "fullname". Rectify this by always storing the FQN in the tree metadata.
... While we're here, re-organize the code in preparation for namespace support to make it a bit easier to add additional components of the FQN. With this change, there is now extremely little code left that's taken directly from the Python domain :)
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250313044312.189276-3-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
8fad3662 |
| 12-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi_domain: isolate TYPE_CHECKING imports
When using the annotations feature, type hints do not need to be imported at runtime, only at type check time. Move type-check-only imports into a con
docs/qapi_domain: isolate TYPE_CHECKING imports
When using the annotations feature, type hints do not need to be imported at runtime, only at type check time. Move type-check-only imports into a conditional to reduce the number of imports needed at runtime.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250313044312.189276-2-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
94d689d0 |
| 11-Mar-2025 |
Stefan Hajnoczi <stefanha@redhat.com> |
Merge tag 'pull-qapi-2025-03-11' of https://repo.or.cz/qemu/armbru into staging
QAPI patches patches for 2025-03-11
# -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEENUvIs9frKmtoZ05fOHC0AOuRhlMFA
Merge tag 'pull-qapi-2025-03-11' of https://repo.or.cz/qemu/armbru into staging
QAPI patches patches for 2025-03-11
# -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEENUvIs9frKmtoZ05fOHC0AOuRhlMFAmfQCnkSHGFybWJydUBy # ZWRoYXQuY29tAAoJEDhwtADrkYZTsJ0P/jcXiyFxjcbXN/3a6+iuPPqlviiWPAKG # db2aHn2divceFEf7hUrwqjiJIPLDxaq6iJy71bjPUDkE8wAEdsf2zD7ryHo+sGcO # rWaSaHmonn0QHvqcvkGGrbmTH+Ezl1RpP8XVGfG2lmHbjPQ3+EYnRwML6jC8dnvR # C7qkyQ+qxmdV2lWb4MalgABKZToZ2aqnI9lr9KzHmN+55i2OxJrhECUKDHcgtG2i # Pqc1GLGmmQ4Wj+4z0PyvKYZS4LP/90eH8bNyeA6TVsPHxgG79pencct7DOHxhc8q # hHQ1TaqcBeWFQ7tndLMNDnHjm9XpAzMuew87xMTo6R450JxiSn+AkioTE0L563hy # SjeXmIQ8COZbHsuSKlFJcV1OS1c/mJbwpkxptyaMLjTt2Lp9geFs39WKWHcs8pCN # EmWSdvoqmP7D4bp1hXAVSPIIvJ7L2NwnM8ONH0KmRD5uMQrjiHsfvyWHAVnT10yu # 8822hjlJp7l3B1QCi19mTlkiztCFScjb3Se8A+jScP5iX0q9C4H4t+tAw2m4UY1V # pvn4xFxV82CvR3uQI0OMTKhp0/eEfvBioA1PEXOegPH5cS/L7YFF59mta1dCnaL7 # 0JRRCsTAnwAAAXoEteGqF1/6tXBdOnroL0OvHXJQVb2HH5c5YTnuxMiQywcP6Jty # wt1vl42jfTj1 # =Gt4B # -----END PGP SIGNATURE----- # gpg: Signature made Tue 11 Mar 2025 18:03:37 HKT # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653
* tag 'pull-qapi-2025-03-11' of https://repo.or.cz/qemu/armbru: (61 commits) scripts/qapi/backend: Clean up create_backend()'s failure mode MAINTAINERS: Add jsnow as maintainer for Sphinx documentation docs: add qapi-domain syntax documentation docs: enable qapidoc transmogrifier for QEMU QMP Reference docs: disambiguate cross-references qapi/parser: add undocumented stub members to all_sections docs/qapidoc: generate entries for undocumented members docs/qapidoc: Add "the members of" pointers docs/qapidoc: add intermediate output debugger docs/qapidoc: process @foo into ``foo`` docs/qapidoc: implement transmogrify() method docs/qapidoc: add visit_entity() docs/qapidoc: add visit_sections() method docs/qapidoc: add visit_member() method docs/qapidoc: add visit_returns() method docs/qapidoc: prepare to record entity being transmogrified docs/qapidoc: add visit_feature() method docs/qapidoc: add add_field() and generate_field() helper methods docs/qapidoc: add format_type() method docs/qapidoc: add visit_errors() method ...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
show more ...
|
#
1884492e |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapidoc: Add "the members of" pointers
Add "the members of ..." pointers to Members and Arguments lists where appropriate, with clickable cross-references - so it's a slight improvement over th
docs/qapidoc: Add "the members of" pointers
Add "the members of ..." pointers to Members and Arguments lists where appropriate, with clickable cross-references - so it's a slight improvement over the old system :)
This patch is meant to be a temporary solution until we can review and merge the inliner.
The implementation of this patch is a little bit of a hack: Sphinx is not designed to allow you to mix fields of different "type"; i.e. mixing member descriptions and free-form text under the same heading. To accomplish this with a minimum of hackery, we technically document a "dummy field" and then just strip off the documentation for that dummy field in a post-processing step. We use the "q_dummy" variable for this purpose, then strip it back out before final processing. If this processing step should fail, you'll see warnings for a bad cross-reference. (So if you don't see any, it must be working!)
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-58-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
707f2bbb |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: Fix error context reporting in Sphinx 5.x and 6.x
Sphinx 5.3.0 to Sphinx 6.2.0 has a bug where nested content in an ObjectDescription content block has its error position reported
docs/qapi-domain: Fix error context reporting in Sphinx 5.x and 6.x
Sphinx 5.3.0 to Sphinx 6.2.0 has a bug where nested content in an ObjectDescription content block has its error position reported incorrectly due to an oversight when they added nested section support to this directive.
(This bug is present in Sphinx's own Python and C domains; test it yourself by creating a py:func directive and creating a syntax error in the directive's content block. The reporting will be incorrect.)
To avoid overriding and re-implementing the entirety of the run() method, a workaround is employed where we parse the content block ourselves in before_content(), then null the content block to make Sphinx's own parsing a no-op. Then, in transform_content (which occurs after Sphinx's nested parse), we simply swap our own parsed content tree back in for Sphinx's.
It appears a little tricky, but it's the nicest solution I can find.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-32-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
d48a8f8d |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: warn when QAPI domain xrefs fail to resolve
This patch adds a warning (which is a build failure under our current build settings) whenever a QAPI cross-reference fails to resolve.
docs/qapi-domain: warn when QAPI domain xrefs fail to resolve
This patch adds a warning (which is a build failure under our current build settings) whenever a QAPI cross-reference fails to resolve.
This applies to any cross-references of the form :qapi:{role}:`foo`, which covers all of the automatically generated references by the qapi domain, and any such references that are manually written into the documentation rst files.
Cross-references of the form `foo` do not use this system, but are already configured to issue a warning (Again, a build failure) if the cross-reference isn't found anywhere.
Adds warnings that look like the following:
docs/qapi/index.rst:48: WARNING: qapi:type reference target not found: 'footype' [ref.qapi] docs/qapi/index.rst:50: WARNING: qapi:mod reference target not found: 'foomod' [ref.qapi]
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-31-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
a1fe2cd4 |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add XREF compatibility goop for Sphinx < 4.1
Sphinx < 4.1 handles cross-references ... differently. Factor out and isolate the compatibility goop we need to make cross references w
docs/qapi-domain: add XREF compatibility goop for Sphinx < 4.1
Sphinx < 4.1 handles cross-references ... differently. Factor out and isolate the compatibility goop we need to make cross references work properly in old versions of Sphinx.
Yes, it's ugly. Yes, it works. No, I don't want to talk about it.
Understand that this patch exists because of the overflowing love in my heart.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-30-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
03947c80 |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add type cross-refs to field lists
This commit, finally, adds cross-referencing support to various field lists; modeled tightly after Sphinx's own Python domain code.
Cross-refere
docs/qapi-domain: add type cross-refs to field lists
This commit, finally, adds cross-referencing support to various field lists; modeled tightly after Sphinx's own Python domain code.
Cross-referencing support is added to type names provided to :arg:, :memb:, :returns: and :choice:.
:feat:, :error: and :value:, which do not take type names, do not support this syntax.
The general syntax is simple:
:arg TypeName ArgName: Lorem Ipsum ...
The domain will transform TypeName into :qapi:type:`TypeName` in this basic case, and also apply the ``literal`` decoration to indicate that this is a type cross-reference.
For optional arguments, the special "?" suffix is used. Because "*" has special meaning in rST that would cause parsing errors, we elect to use "?" instead. The special syntax processing strips this character from the end of any type name argument and will append ", optional" to the rendered output, applying the cross-reference only to the actual type name.
The intent here is that the actual syntax in doc-blocks need not change; but e.g. qapidoc.py will need to process and transform "@arg foo lorem ipsum" into ":arg type? foo: lorem ipsum" based on the schema information. Therefore, nobody should ever actually witness this intermediate syntax unless they are writing manual documentation or the doc transmogrifier breaks.
For array arguments, type names can similarly be surrounded by "[]", which are stripped off and then re-appended outside of the cross-reference.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-28-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
ef137a22 |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add warnings for malformed field lists
Normally, Sphinx will silently fall back to its standard field list processing if it doesn't match one of your defined fields. A lot of the t
docs/qapi-domain: add warnings for malformed field lists
Normally, Sphinx will silently fall back to its standard field list processing if it doesn't match one of your defined fields. A lot of the time, that's not what we want - we want to be warned if we goof something up.
For instance, the canonical argument field list form is:
:arg type name: descr
This form is captured by Sphinx and transformed so that the field label will become "Arguments:". It's possible to omit the type name and descr and still have it be processed correctly. However, if you omit the type name, Sphinx no longer recognizes it:
:arg: this is not recognized.
This will turn into an arbitrary field list entry whose label is "Arg:", and it otherwise silently fails. You may also see failures for doing things like using :values: instead of :value:, or :errors: instead of :error:, and so on. It's also case sensitive, and easy to trip up.
Add a validator that guarantees all field list entries that are the direct child of an ObjectDescription use only recognized forms of field lists, and emit a warning (treated as error by default in most build configurations) whenever we detect one that is goofed up.
However, there's still benefit to allowing arbitrary fields -- they are after all not a Sphinx invention, but perfectly normal docutils syntax. Create an allow list for known spellings we don't mind letting through, but warn against anything else.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-27-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
6a413302 |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add :ifcond: directive option
Add a special :ifcond: option that allows us to annotate the definition-level conditionals.
The syntax of the argument is currently undefined, but it
docs/qapi-domain: add :ifcond: directive option
Add a special :ifcond: option that allows us to annotate the definition-level conditionals.
The syntax of the argument is currently undefined, but it's possible we can apply better formatting in the future. Currently, we just display the ifcond string as preformatted text.
Signed-off-by: Harmonie Snow <harmonie@gmail.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-26-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
d25808c2 |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add :unstable: directive option
Although "unstable" is a feature (and *will* appear in the features list), add a special :unstable: option to generate an eye-catch that makes this
docs/qapi-domain: add :unstable: directive option
Although "unstable" is a feature (and *will* appear in the features list), add a special :unstable: option to generate an eye-catch that makes this information very hard to miss.
The forthcoming Transmogrifier in qapidoc.py will add this option whenever it detects that the features list attached to a definition contains the "unstable" entry.
Signed-off-by: Harmonie Snow <harmonie@gmail.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-25-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
1a0c090a |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add :deprecated: directive option
Although "deprecated" is a feature (and *will* appear in the features list), add a special :deprecated: option to generate an eye-catch that makes
docs/qapi-domain: add :deprecated: directive option
Although "deprecated" is a feature (and *will* appear in the features list), add a special :deprecated: option to generate an eye-catch that makes this information very hard to miss.
The forthcoming Transmogrifier in qapidoc.py will add this option whenever it detects that the features list attached to a definition contains the "deprecated" entry.
P.S., I outsourced the CSS ;)
Signed-off-by: Harmonie Snow <harmonie@gmail.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-24-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
3fe3349d |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add qapi:object directive
Adds the .. qapi:object:: directive, object, and :qapi:obj:`name` cross-referencing role. This directive is meant to document both structs and unions.
As
docs/qapi-domain: add qapi:object directive
Adds the .. qapi:object:: directive, object, and :qapi:obj:`name` cross-referencing role. This directive is meant to document both structs and unions.
As per usual, QAPI cross-referencing for types in the member field list will be added in a forthcoming commit.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-23-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
6d5f6f69 |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add qapi:event directive
Adds the .. qapi:event:: directive, object, and :qapi:event:`name` cross-referencing role.
Adds the :memb type name: field list syntax for documenting eve
docs/qapi-domain: add qapi:event directive
Adds the .. qapi:event:: directive, object, and :qapi:event:`name` cross-referencing role.
Adds the :memb type name: field list syntax for documenting event data members. As this syntax and phrasing will be shared with Structs and Unions as well, add the field list definition to a shared abstract class.
As per usual, QAPI cross-referencing for types in the member field list will be added in a forthcoming commit.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-22-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
bac3f131 |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add qapi:alternate directive
Add the .. qapi:alternate:: directive, object, and qapi:alt:`name` cross-reference role.
Add the "Alternatives:" field list for describing alternate c
docs/qapi-domain: add qapi:alternate directive
Add the .. qapi:alternate:: directive, object, and qapi:alt:`name` cross-reference role.
Add the "Alternatives:" field list for describing alternate choices. Like other field lists that reference QAPI types, a forthcoming commit will add cross-referencing support to this field.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-21-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
902c9b0e |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add qapi:enum directive
Add the .. qapi:enum:: directive, object, and :qapi:enum:`name` cross-reference role.
Add the :value name: field list for documenting Enum values.
Of note
docs/qapi-domain: add qapi:enum directive
Add the .. qapi:enum:: directive, object, and :qapi:enum:`name` cross-reference role.
Add the :value name: field list for documenting Enum values.
Of note, also introduce a new "type" role that is intended to be used by other QAPI object directives to cross-reference arbitrary QAPI type names, but will exclude commands, events, and modules from consideration.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-20-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
8b77f8d5 |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add "Return:" field lists
Add "Return:" field list syntax to QAPI Commands.
Like "Arguments:" and "Errors:", the type name isn't currently processed for cross-referencing, but thi
docs/qapi-domain: add "Return:" field lists
Add "Return:" field list syntax to QAPI Commands.
Like "Arguments:" and "Errors:", the type name isn't currently processed for cross-referencing, but this will be addressed in a forthcoming commit.
The syntax of the new field is:
:return TypeName: description description cont'd
This patch adds "Return" as a GroupedField, which means that multiple return values can be annotated - this is only done because Sphinx does not support mandatory type arguments to Ungrouped fields. Because we want to cross-reference this type information later, we want to make the type argument mandatory. As a result, you can technically add multiple :return: fields, though I'm not aware of any circumstance in which you'd need or want to. Recommendation: "Don't do that, then." The forthcoming QAPIDoc transmogrifier does not, in fact, ever "do that".
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-19-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
9605c204 |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add "Errors:" field lists
``:error: descr`` can now be used to document error conditions. The format of the description is not defined here; so the ability to name specific types i
docs/qapi-domain: add "Errors:" field lists
``:error: descr`` can now be used to document error conditions. The format of the description is not defined here; so the ability to name specific types is left to the document writer.
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-18-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
#
3d9a23f9 |
| 10-Mar-2025 |
John Snow <jsnow@redhat.com> |
docs/qapi-domain: add "Features:" field lists
Add support for Features field lists. There is no QAPI-specific functionality here, but this could be changed if desired (if we wanted the feature names
docs/qapi-domain: add "Features:" field lists
Add support for Features field lists. There is no QAPI-specific functionality here, but this could be changed if desired (if we wanted the feature names to link somewhere, for instance.)
This feature list doesn't have any restrictions, so it can be used to document object-wide features or per-member features as deemed appropriate. It's essentially free-form text.
The syntax for this field is:
:feat name: description description cont'd
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250311034303.75779-17-jsnow@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|