In commit 26ec4e53f2 and similar commits we fixed the indentation
for doc comments in our qapi json files to follow a new stricter
standard for indentation, which permits only:
@arg: description line 1
description line 2
or:
@arg:
line 1
line 2
but because the script updates that enforce this are not yet in the
tree we have had a steady trickle of subsequent changes which didn't
follow the new rules.
Fix the latest round of mis-indented doc comments.
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
---
qapi/block-core.json | 4 +-
qapi/migration.json | 102 +++++++++++++++++++++----------------------
2 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 3c16f1e11d6..dd77a91174c 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -4316,8 +4316,8 @@
# @data-file-raw: True if the external data file must stay valid as a
# standalone (read-only) raw image without looking at qcow2
# metadata (default: false; since: 4.0)
-# @extended-l2 True to make the image have extended L2 entries
-# (default: false; since 5.2)
+# @extended-l2: True to make the image have extended L2 entries
+# (default: false; since 5.2)
# @size: Size of the virtual disk in bytes
# @version: Compatibility level (default: v3)
# @backing-file: File name of the backing file if a backing file
diff --git a/qapi/migration.json b/qapi/migration.json
index 675f70bb673..b89052c6fd3 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -681,23 +681,23 @@
# Defaults to 1. (Since 5.0)
#
# @block-bitmap-mapping: Maps block nodes and bitmaps on them to
-# aliases for the purpose of dirty bitmap migration. Such
-# aliases may for example be the corresponding names on the
-# opposite site.
-# The mapping must be one-to-one, but not necessarily
-# complete: On the source, unmapped bitmaps and all bitmaps
-# on unmapped nodes will be ignored. On the destination,
-# encountering an unmapped alias in the incoming migration
-# stream will result in a report, and all further bitmap
-# migration data will then be discarded.
-# Note that the destination does not know about bitmaps it
-# does not receive, so there is no limitation or requirement
-# regarding the number of bitmaps received, or how they are
-# named, or on which nodes they are placed.
-# By default (when this parameter has never been set), bitmap
-# names are mapped to themselves. Nodes are mapped to their
-# block device name if there is one, and to their node name
-# otherwise. (Since 5.2)
+# aliases for the purpose of dirty bitmap migration.
Such
+# aliases may for example be the corresponding names on
the
+# opposite site.
+# The mapping must be one-to-one, but not necessarily
+# complete: On the source, unmapped bitmaps and all
bitmaps
+# on unmapped nodes will be ignored. On the
destination,
+# encountering an unmapped alias in the incoming
migration
+# stream will result in a report, and all further bitmap
+# migration data will then be discarded.
+# Note that the destination does not know about bitmaps
it
+# does not receive, so there is no limitation or
requirement
+# regarding the number of bitmaps received, or how they
are
+# named, or on which nodes they are placed.
+# By default (when this parameter has never been set),
bitmap
+# names are mapped to themselves. Nodes are mapped to
their
+# block device name if there is one, and to their node
name
+# otherwise. (Since 5.2)
#
# Since: 2.4
##
@@ -841,23 +841,23 @@
# Defaults to 1. (Since 5.0)
#
# @block-bitmap-mapping: Maps block nodes and bitmaps on them to
-# aliases for the purpose of dirty bitmap migration. Such
-# aliases may for example be the corresponding names on the
-# opposite site.
-# The mapping must be one-to-one, but not necessarily
-# complete: On the source, unmapped bitmaps and all bitmaps
-# on unmapped nodes will be ignored. On the destination,
-# encountering an unmapped alias in the incoming migration
-# stream will result in a report, and all further bitmap
-# migration data will then be discarded.
-# Note that the destination does not know about bitmaps it
-# does not receive, so there is no limitation or requirement
-# regarding the number of bitmaps received, or how they are
-# named, or on which nodes they are placed.
-# By default (when this parameter has never been set), bitmap
-# names are mapped to themselves. Nodes are mapped to their
-# block device name if there is one, and to their node name
-# otherwise. (Since 5.2)
+# aliases for the purpose of dirty bitmap migration.
Such
+# aliases may for example be the corresponding names on
the
+# opposite site.
+# The mapping must be one-to-one, but not necessarily
+# complete: On the source, unmapped bitmaps and all
bitmaps
+# on unmapped nodes will be ignored. On the
destination,
+# encountering an unmapped alias in the incoming
migration
+# stream will result in a report, and all further bitmap
+# migration data will then be discarded.
+# Note that the destination does not know about bitmaps
it
+# does not receive, so there is no limitation or
requirement
+# regarding the number of bitmaps received, or how they
are
+# named, or on which nodes they are placed.
+# By default (when this parameter has never been set),
bitmap
+# names are mapped to themselves. Nodes are mapped to
their
+# block device name if there is one, and to their node
name
+# otherwise. (Since 5.2)
#
# Since: 2.4
##
@@ -1037,23 +1037,23 @@
# Defaults to 1. (Since 5.0)
#
# @block-bitmap-mapping: Maps block nodes and bitmaps on them to
-# aliases for the purpose of dirty bitmap migration. Such
-# aliases may for example be the corresponding names on the
-# opposite site.
-# The mapping must be one-to-one, but not necessarily
-# complete: On the source, unmapped bitmaps and all bitmaps
-# on unmapped nodes will be ignored. On the destination,
-# encountering an unmapped alias in the incoming migration
-# stream will result in a report, and all further bitmap
-# migration data will then be discarded.
-# Note that the destination does not know about bitmaps it
-# does not receive, so there is no limitation or requirement
-# regarding the number of bitmaps received, or how they are
-# named, or on which nodes they are placed.
-# By default (when this parameter has never been set), bitmap
-# names are mapped to themselves. Nodes are mapped to their
-# block device name if there is one, and to their node name
-# otherwise. (Since 5.2)
+# aliases for the purpose of dirty bitmap migration.
Such
+# aliases may for example be the corresponding names on
the
+# opposite site.
+# The mapping must be one-to-one, but not necessarily
+# complete: On the source, unmapped bitmaps and all
bitmaps
+# on unmapped nodes will be ignored. On the
destination,
+# encountering an unmapped alias in the incoming
migration
+# stream will result in a report, and all further bitmap
+# migration data will then be discarded.
+# Note that the destination does not know about bitmaps
it
+# does not receive, so there is no limitation or
requirement
+# regarding the number of bitmaps received, or how they
are
+# named, or on which nodes they are placed.
+# By default (when this parameter has never been set),
bitmap
+# names are mapped to themselves. Nodes are mapped to
their
+# block device name if there is one, and to their node
name
+# otherwise. (Since 5.2)
#
# Since: 2.4
##
--
2.20.1
