On 02/14/2017 07:05 AM, Vladimir Sementsov-Ogievskiy wrote:
> 11.02.2017 02:20, John Snow wrote:
>> On 02/03/2017 04:40 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> +void bdrv_store_persistent_dirty_bitmaps(BlockDriverState *bs, Error
>>> **errp)
>>> +{
>>> + BlockDriver *drv = bs->drv;
>>> +
>>> + if (!bdrv_has_persistent_bitmaps(bs)) {
>>> + return;
>>> + }
>>> +
>>> + if (!drv) {
>>> + error_setg_errno(errp, ENOMEDIUM,
>>> + "Can't store persistent bitmaps to %s",
>>> + bdrv_get_device_or_node_name(bs));
>>> + return;
>>> + }
>>> +
>>> + if (!drv->bdrv_store_persistent_dirty_bitmaps) {
>>> + error_setg_errno(errp, ENOTSUP,
>>> + "Can't store persistent bitmaps to %s",
>>> + bdrv_get_device_or_node_name(bs));
>>> + return;
>>> + }
>>> +
>> I suppose this is for the case for where we have added a persistent
>> bitmap during runtime, but the driver does not support it?
>>
>> I'd rather fail this type of thing earlier if possible, but I'm not that
>> far in your series yet.
>
> qmp bitmap add checks for availability of
> drv->bdrv_can_store_new_dirty_bitmap,
> and loaded bitmaps of course should be attached to bds with appropriate
> driver.
> So, it is mostly a paranoic check.
>
OK, understood. Not a problem, then.
--js
