[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v8 03/36] block: Introduce image file locking
From: |
Max Reitz |
Subject: |
Re: [Qemu-block] [PATCH v8 03/36] block: Introduce image file locking |
Date: |
Tue, 25 Oct 2016 15:21:09 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
On 25.10.2016 07:48, Fam Zheng wrote:
> On Fri, 10/21 23:04, Max Reitz wrote:
[...]
>>> +int bdrv_set_lock_mode(BlockDriverState *bs, ImageLockMode mode)
>>> +{
>>> + int ret;
>>> +
>>> + if (bs->cur_lock == mode) {
>>> + return 0;
>>> + } else if (!bs->drv) {
>>> + return -ENOMEDIUM;
>>> + } else if (!bs->drv->bdrv_lockf) {
>>> + if (bs->file) {
>>> + return bdrv_set_lock_mode(bs->file->bs, mode);
>>> + }
>>> + return 0;
>>> + }
>>> + ret = bs->drv->bdrv_lockf(bs, mode);
>>> + if (ret == -ENOTSUP) {
>>> + /* Handle it the same way as !bs->drv->bdrv_lockf */
>>> + ret = 0;
>>
>> Yes, well, why do you handle both as success? Wouldn't returning
>> -ENOTSUP make more sense?
>>
>> I guess the caller can find out itself by checking whether bs->cur_lock
>> has changed, but...
>
> I can't think of a reason for any caller to do something different for
> -ENOTSUP
> from success, hence the check here.
OK, that's fine, then.
Max
signature.asc
Description: OpenPGP digital signature