From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz060-0004qc-3A for qemu-devel@nongnu.org; Tue, 16 Jul 2013 03:54:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uz05x-0008KE-Mg for qemu-devel@nongnu.org; Tue, 16 Jul 2013 03:54:52 -0400 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:59705 helo=mx01.kamp.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Uz05x-0008Jz-CE for qemu-devel@nongnu.org; Tue, 16 Jul 2013 03:54:49 -0400 Message-ID: <51E4FC46.3000201@kamp.de> Date: Tue, 16 Jul 2013 09:54:46 +0200 From: Peter Lieven 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> In-Reply-To: <51E4F3F0.9030200@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Paolo Bonzini Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com 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. Peter