qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCHv5] block/get_block_status: avoid redundant callo


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCHv5] block/get_block_status: avoid redundant callouts on raw devices
Date: Tue, 8 Oct 2013 13:13:36 +0200

On Mon, Oct 7, 2013 at 10:25 AM, Paolo Bonzini <address@hidden> wrote:
> Il 07/10/2013 07:59, Peter Lieven ha scritto:
>> if a raw device like an iscsi target or host device is used
>> the current implementation makes a second call out to get
>> the block status of bs->file.
>>
>> Signed-off-by: Peter Lieven <address@hidden>
>> ---
>> v5: add a generic get_lba_status function in the raw driver which
>>     adds the BDRV_BLOCK_RAW flag. bdrv_co_get_block_status will
>>     handle the callout to bs->file then.
>>
>> v4: use a flag to detect the raw driver instead of the strncmp
>>     hack
>>
>>  block.c               |    4 ++++
>>  block/raw_bsd.c       |    3 ++-
>>  include/block/block.h |    4 ++++
>>  3 files changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/block.c b/block.c
>> index 93e113a..38a589e 100644
>> --- a/block.c
>> +++ b/block.c
>> @@ -3147,6 +3147,10 @@ static int64_t coroutine_fn 
>> bdrv_co_get_block_status(BlockDriverState *bs,
>>          return ret;
>>      }
>>
>> +    if (ret & BDRV_BLOCK_RAW) {
>> +        return bdrv_get_block_status(bs->file, sector_num, nb_sectors, 
>> pnum);
>
> Strictly speaking, this should probably do something like this:
>
>   assert(ret & BDRV_BLOCK_OFFSET_VALID);
>   return bdrv_get_block_status(bs->file, ret >> BDRV_SECTOR_BITS,
>                                nb_sectors, pnum);
>
> Or alternatively the raw driver should return just "BDRV_BLOCK_RAW".
>
> As a third option, the raw driver could also return not just
> BDRV_BLOCK_RAW and BDRV_BLOCK_OFFSET_VALID, but also BDRV_BLOCK_DATA (so
> that the answer makes some sense even without going down to bs->file).
>
> But I'll let the block maintainers decide what to do.

The return value is a bitfield, so let's use those bits and take Option 3.

Stefan



reply via email to

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