qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 11/24] block: introduce persistent dirty bitmaps


From: John Snow
Subject: Re: [Qemu-devel] [PATCH 11/24] block: introduce persistent dirty bitmaps
Date: Tue, 14 Feb 2017 12:35:41 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]