Re: [Qemu-devel] [PATCH 16/17] block: add default get_block_status implementation for protocols

[Paolo Bonzini <pbonzini@redhat.com>]

Il 17/07/2013 12:26, Peter Lieven ha scritto:
> 
> Am 16.07.2013 um 09:19 schrieb Paolo Bonzini <pbonzini@redhat.com>:
> 
>> Il 16/07/2013 08:47, Peter Lieven ha scritto:
>>>>
>>>> @@ -2977,7 +2977,11 @@ static int64_t coroutine_fn
>>>> bdrv_co_get_block_status(BlockDriverState *bs,
>>>>        if (!bs->drv->bdrv_co_get_block_status) {
>>>>          *pnum = nb_sectors;
>>>> -        return BDRV_BLOCK_DATA;
>>>> +        ret = BDRV_BLOCK_DATA;
>>>> +        if (bs->drv->protocol_name) {
>>>> +            ret |= BDRV_BLOCK_OFFSET_VALID | (sector_num *
>>>> BDRV_SECTOR_SIZE);
>>>> +        }
>>>> +        return ret;
>>>>      }
>>>>        ret = bs->drv->bdrv_co_get_block_status(bs, sector_num,
>>>> nb_sectors, pnum);
>>> I am curious if this is right. Doesn't this mean we say that at offset
>>> sector_num * BDRV_SECTOR_SIZE are nb_sectors of linear data? This is
>>> something we do not know for sure.
>>
>> Only for protocols.  In this case, we do know, or format=raw wouldn't
>> work.  This is not propagated up to the actual BDS for the image, except
>> for format=raw.
> 
> Wouldn't it be better to add this general tweak in to raw_co_is_allocated
> rather than at the block level?

No, this is not a "general tweak".  It is a default implementation (it
is protected by "if (!bs->drv->bdrv_co_get_block_status)".  Other
implementations can do the same, for example raw-posix.c also returns
BDRV_BLOCK_OFFSET_VALID | (sector_num * BDRV_SECTOR_SIZE).

Each layer must return complete data.  If a higher layer wants to query
bs->file, it must obviously filters those flags that still make sense.

In the case of format=raw, all flags make sense.  For other layers, some
flags may not make sense and have to be stripped.

> What you write above is true, but you will never know what will happen in the
> future. For raw this tweak is right, but for anything developed in the future
> it might not be and in the end nobody remembers to fix it at this position.

Does the above explain it better?

Paolo