From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuuDp-0004WV-5m for qemu-devel@nongnu.org; Thu, 04 Jul 2013 20:50:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UuuDm-0000Oe-Fa for qemu-devel@nongnu.org; Thu, 04 Jul 2013 20:50:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuuDm-0000OY-6B for qemu-devel@nongnu.org; Thu, 04 Jul 2013 20:49:58 -0400 Date: Fri, 5 Jul 2013 08:49:50 +0800 From: Fam Zheng Message-ID: <20130705004950.GA1570@T430s.nay.redhat.com> References: <1372862071-28225-1-git-send-email-pbonzini@redhat.com> <1372862071-28225-11-git-send-email-pbonzini@redhat.com> <5B1A6BCB-5A72-4A2F-A1D3-5DEDA9FB59D2@kamp.de> <51D52EB3.2000508@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 10/17] block: define get_block_status return value Reply-To: famz@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: kwolf@redhat.com, Paolo Bonzini , qemu-devel@nongnu.org, stefanha@redhat.com On Thu, 07/04 23:10, Peter Lieven wrote: > > Am 04.07.2013 um 10:13 schrieb Paolo Bonzini : > > > Il 03/07/2013 23:04, Peter Lieven ha scritto: > >>>> Define the return value of get_block_status. Bits 0, 1, 2 and 8-62 > >>>> are valid; bit 63 (the sign bit) is reserved for errors. Bits 3-7 > >>>> are left for future extensions. > >> Is Bit 8 not also reserved for future use? BDRV_SECTOR_BITS is 9. > > > > Right. > > > >> Can you explain which information is exactly returned in Bits 9-62? > > > > Bits 9-62 are the offset at which the data is stored in bs->file, they > > are valid if bit 2 (BDRV_BLOCK_OFFSET_VALID) is 1. > > Ok, so this is if bs->file is not linear? > > If we return the offset into bs->file this would only make sense if the data > at that position is raw and not encoded otherwise and if *pnum is limited > to the size of the extend at that position, right? Exactly. > > I currently do not understand for what operation this info is needed. Quoted from the cover letter: > One example usage is > (for non-compressed, non-encrypted images) to transform the metadata > into a Linux device-mapper setup, and make a qcow2 image available (for > read only) as a block device. Another possible usage is to determine > the used areas of a file, and convert it in place to another format. Thanks. Fam