Re: [Qemu-devel] [PATCH v3 2/2] qapi: Change BlockDirtyInfo to list

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On 11/13/2013 07:19 AM, Kevin Wolf wrote:

>>  #
>> -# @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.

Indeed, expanding the per-job query output to list a single dirty bitmap
tied to that job is probably more useful than listing all dirty bitmaps
without context here.  Since it's output-only, and marked optional, we
can still withdraw this output even after 1.8 if we decide we don't like
it and no one has reported wanting to use it.

I was going to suggest _always_ outputting dirty-bitmaps, even if it is
an empty array, if that makes it easier to detect that yes, this is a
version of qemu new enough to have per-job dirty bitmaps but there are
no jobs at the moment; on the other hand, doing that would mean the
field is not marked optional, and then we would always have to output it
for back-compat reasons.  So keeping the field marked optional makes sense.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]