Am 13.11.2013 um 11:29 hat Fam Zheng geschrieben:
> We have multiple dirty bitmaps in BDS now, switch QAPI to allow query
> it (BlockInfo.dirty_bitmaps), and also drop old BlockInfo.dirty.
>
> Signed-off-by: Fam Zheng <f...@redhat.com>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 81a375b..931d710 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -948,8 +948,8 @@
> # @tray_open: #optional True if the device has a tray and it is open
> # (only present if removable is true)
> #
> -# @dirty: #optional dirty bitmap information (only present if the dirty
> -# bitmap is enabled)
> +# @dirty-bitmaps: #optional dirty bitmaps information (only present if the
> +# driver has one or more dirty bitmaps)
> #
> # @io-status: #optional @BlockDeviceIoStatus. Only present if the device
> # supports it and the VM is configured to stop on errors
> @@ -963,7 +963,7 @@
> 'data': {'device': 'str', 'type': 'str', 'removable': 'bool',
> 'locked': 'bool', '*inserted': 'BlockDeviceInfo',
> '*tray_open': 'bool', '*io-status': 'BlockDeviceIoStatus',
> - '*dirty': 'BlockDirtyInfo' } }
> + '*dirty-bitmaps': ['BlockDirtyInfo'] } }
>
> ##
> # @query-block:
I believe this is of limited use; if you ever have more than one dirty
bitmap, we're lacking information to associate it with the job it
belongs to. One option would be to extend BlockDirtyInfo to indicate
this, but another might be to actually extend other commands like
query-block-jobs to return information on the dirty bitmap associated
with a specific job.
I've applied it to block-next anyway, we still have some time to
reconsider for 1.8.
Kevin
