mirror of
https://gitlab.com/qemu-project/qemu
synced 2024-11-05 20:35:44 +00:00
qapi: Fix doc comment indentation again
In commit26ec4e53f2
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.maydell@linaro.org> Message-Id: <20200925162316.21205-2-peter.maydell@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Updated for commit4c437254b8
anda83e24ba1a
] Signed-off-by: Markus Armbruster <armbru@redhat.com>
This commit is contained in:
parent
61c7f9876a
commit
826bd0690f
3 changed files with 59 additions and 57 deletions
|
@ -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
|
||||
|
|
|
@ -1001,9 +1001,11 @@
|
|||
#
|
||||
# Request the balloon driver to change its balloon size.
|
||||
#
|
||||
# @value: the target logical size of the VM in bytes
|
||||
# @value: the target logical size of the VM in bytes.
|
||||
# We can deduce the size of the balloon using this formula:
|
||||
#
|
||||
# logical_vm_size = vm_ram_size - balloon_size
|
||||
#
|
||||
# From it we have: balloon_size = vm_ram_size - @value
|
||||
#
|
||||
# Returns: - Nothing on success
|
||||
|
|
|
@ -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
|
||||
##
|
||||
|
@ -1744,9 +1744,9 @@
|
|||
# Information about current dirty page rate of vm.
|
||||
#
|
||||
# @dirty-rate: @dirtyrate describing the dirty page rate of vm
|
||||
# in units of MB/s.
|
||||
# If this field returns '-1', it means querying has not
|
||||
# yet started or completed.
|
||||
# in units of MB/s.
|
||||
# If this field returns '-1', it means querying has not
|
||||
# yet started or completed.
|
||||
#
|
||||
# @status: status containing dirtyrate query status includes
|
||||
# 'unstarted' or 'measuring' or 'measured'
|
||||
|
|
Loading…
Reference in a new issue