From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz1ho-0000rj-6W for qemu-devel@nongnu.org; Tue, 16 Jul 2013 05:38:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uz1hm-0002ly-3X for qemu-devel@nongnu.org; Tue, 16 Jul 2013 05:38:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6529) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz1hl-0002lo-R1 for qemu-devel@nongnu.org; Tue, 16 Jul 2013 05:37:58 -0400 Message-ID: <51E51466.9070607@redhat.com> Date: Tue, 16 Jul 2013 11:37:42 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1372862071-28225-1-git-send-email-pbonzini@redhat.com> <1372862071-28225-17-git-send-email-pbonzini@redhat.com> <51E4EC9C.70602@kamp.de> <51E4F3F0.9030200@redhat.com> <51E4FC46.3000201@kamp.de> In-Reply-To: <51E4FC46.3000201@kamp.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 16/17] block: add default get_block_status implementation for protocols List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com Il 16/07/2013 09:54, Peter Lieven ha scritto: > On 16.07.2013 09:19, Paolo Bonzini wrote: >> 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. > If bs->drv->protocol_name is only != NULL if format=raw, I am > fine with this. No, bs->drv->protocol_name is only != NULL if it is a protocol (like file or iscsi) rather than a format (like raw or qcow2). :) But the user will never call bdrv_co_get_block_status on a protocol (bs->file, roughly), only on a format (bs); and this information is only passed from bs->file to bs for format=raw. Other formats compute the offsets themselves. Paolo