[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [PULL 3/3] docs/bitmaps: use QMP lexer instead of json
From: |
John Snow |
Subject: |
[Qemu-devel] [PULL 3/3] docs/bitmaps: use QMP lexer instead of json |
Date: |
Wed, 10 Jul 2019 15:23:06 -0400 |
The annotated style json we use in QMP documentation is not strict json
and depending on the version of Sphinx (2.0+) or Pygments installed,
might cause the build to fail.
Use the new QMP lexer.
Further, some versions of Sphinx can not apply custom lexers to "code"
directives and require the use of "code-block" directives instead, so
make that change at this time as well.
Tested under:
- Sphinx 1.3.6 and Pygments 2.4
- Sphinx 1.7.6 and Pygments 2.2 (Fedora 29 packages)
- Sphinx 2.0.1 and Pygments 2.4
- Sphinx 3.0.0+/f396b3a783 and Pygments 2.4 (From Sphinx git c4f44bdd)
Reported-by: Aarushi Mehta <address@hidden>
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Eduardo Habkost <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
---
docs/interop/bitmaps.rst | 54 ++++++++++++++++++++--------------------
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/docs/interop/bitmaps.rst b/docs/interop/bitmaps.rst
index c29ac4a854..c20bd37a79 100644
--- a/docs/interop/bitmaps.rst
+++ b/docs/interop/bitmaps.rst
@@ -199,7 +199,7 @@ persistence, and recording state can be adjusted at
creation time.
to create a new, actively recording persistent bitmap:
- .. code:: json
+ .. code-block:: QMP
-> { "execute": "block-dirty-bitmap-add",
"arguments": {
@@ -220,7 +220,7 @@ persistence, and recording state can be adjusted at
creation time.
To create a new, disabled (``-recording``), transient bitmap that tracks
changes in 32KiB segments:
- .. code:: json
+ .. code-block:: QMP
-> { "execute": "block-dirty-bitmap-add",
"arguments": {
@@ -254,7 +254,7 @@ Deletes a bitmap. Bitmaps that are ``+busy`` cannot be
removed.
Remove a bitmap named ``bitmap0`` from node ``drive0``:
- .. code:: json
+ .. code-block:: QMP
-> { "execute": "block-dirty-bitmap-remove",
"arguments": {
@@ -280,7 +280,7 @@ Clears all dirty bits from a bitmap. ``+busy`` bitmaps
cannot be cleared.
Clear all dirty bits from bitmap ``bitmap0`` on node ``drive0``:
- .. code:: json
+ .. code-block:: QMP
-> { "execute": "block-dirty-bitmap-clear",
"arguments": {
@@ -309,7 +309,7 @@ begin being recorded. ``+busy`` bitmaps cannot be enabled.
To set ``+recording`` on bitmap ``bitmap0`` on node ``drive0``:
- .. code:: json
+ .. code-block:: QMP
-> { "execute": "block-dirty-bitmap-enable",
"arguments": {
@@ -347,7 +347,7 @@ writes to begin being ignored. ``+busy`` bitmaps cannot be
disabled.
To set ``-recording`` on bitmap ``bitmap0`` on node ``drive0``:
- .. code:: json
+ .. code-block:: QMP
-> { "execute": "block-dirty-bitmap-disable",
"arguments": {
@@ -393,7 +393,7 @@ in any one source bitmap, the target bitmap will mark that
segment dirty.
``drive0``. If ``new_bitmap`` was empty prior to this command, this achieves
a copy.
- .. code:: json
+ .. code-block:: QMP
-> { "execute": "block-dirty-bitmap-merge",
"arguments": {
@@ -424,7 +424,7 @@ attached to nodes serving as the root for guest devices.
API. This result highlights a bitmap ``bitmap0`` attached to the root node of
device ``drive0``.
- .. code:: json
+ .. code-block:: QMP
-> {
"execute": "query-block",
@@ -562,7 +562,7 @@ new, empty bitmap that records writes from this point in
time forward.
destination. These writes will be recorded in the bitmap
accordingly.
-.. code:: json
+.. code-block:: QMP
-> {
"execute": "transaction",
@@ -650,7 +650,7 @@ Example: Resetting an Incremental Backup Anchor Point
If we want to start a new backup chain with an existing bitmap, we can also
use a transaction to reset the bitmap while making a new full backup:
-.. code:: json
+.. code-block:: QMP
-> {
"execute": "transaction",
@@ -730,7 +730,7 @@ Example: First Incremental Backup
#. Issue an incremental backup command:
- .. code:: json
+ .. code-block:: QMP
-> {
"execute": "drive-backup",
@@ -788,7 +788,7 @@ Example: Second Incremental Backup
#. Issue a new incremental backup command. The only difference here is that we
have changed the target image below.
- .. code:: json
+ .. code-block:: QMP
-> {
"execute": "drive-backup",
@@ -869,7 +869,7 @@ image:
#. Issue a new incremental backup command. Apart from the new destination
image, there is no difference from the last two examples.
- .. code:: json
+ .. code-block:: QMP
-> {
"execute": "drive-backup",
@@ -932,7 +932,7 @@ point in time.
#. Create a full (anchor) backup for each drive, with accompanying bitmaps:
- .. code:: json
+ .. code-block:: QMP
-> {
"execute": "transaction",
@@ -1018,7 +1018,7 @@ point in time.
#. Issue a multi-drive incremental push backup transaction:
- .. code:: json
+ .. code-block:: QMP
-> {
"execute": "transaction",
@@ -1121,7 +1121,7 @@ described above. This example demonstrates the single-job
failure case:
#. Attempt to create an incremental backup via QMP:
- .. code:: json
+ .. code-block:: QMP
-> {
"execute": "drive-backup",
@@ -1139,7 +1139,7 @@ described above. This example demonstrates the single-job
failure case:
#. Receive a pair of events indicating failure:
- .. code:: json
+ .. code-block:: QMP
<- {
"timestamp": {...},
@@ -1175,7 +1175,7 @@ described above. This example demonstrates the single-job
failure case:
#. Retry the command after fixing the underlying problem, such as
freeing up space on the backup volume:
- .. code:: json
+ .. code-block:: QMP
-> {
"execute": "drive-backup",
@@ -1193,7 +1193,7 @@ described above. This example demonstrates the single-job
failure case:
#. Receive confirmation that the job completed successfully:
- .. code:: json
+ .. code-block:: QMP
<- {
"timestamp": {...},
@@ -1233,7 +1233,7 @@ and one succeeds:
#. Issue the transaction to start a backup of both drives.
- .. code:: json
+ .. code-block:: QMP
-> {
"execute": "transaction",
@@ -1267,13 +1267,13 @@ and one succeeds:
#. Receive notice that the Transaction was accepted, and jobs were
launched:
- .. code:: json
+ .. code-block:: QMP
<- { "return": {} }
#. Receive notice that the first job has completed:
- .. code:: json
+ .. code-block:: QMP
<- {
"timestamp": {...},
@@ -1289,7 +1289,7 @@ and one succeeds:
#. Receive notice that the second job has failed:
- .. code:: json
+ .. code-block:: QMP
<- {
"timestamp": {...},
@@ -1365,7 +1365,7 @@ applied:
#. Issue the multi-drive incremental backup transaction:
- .. code:: json
+ .. code-block:: QMP
-> {
"execute": "transaction",
@@ -1401,13 +1401,13 @@ applied:
#. Receive notice that the Transaction was accepted, and jobs were launched:
- .. code:: json
+ .. code-block:: QMP
<- { "return": {} }
#. Receive notification that the backup job for ``drive1`` has failed:
- .. code:: json
+ .. code-block:: QMP
<- {
"timestamp": {...},
@@ -1434,7 +1434,7 @@ applied:
#. Receive notification that the job for ``drive0`` has been cancelled:
- .. code:: json
+ .. code-block:: QMP
<- {
"timestamp": {...},
--
2.21.0