From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaQMW-0000s7-KH for qemu-devel@nongnu.org; Mon, 29 Feb 2016 11:07:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaQMV-0007gv-O3 for qemu-devel@nongnu.org; Mon, 29 Feb 2016 11:07:56 -0500 References: <1456758714-12609-1-git-send-email-eblake@redhat.com> <56D466F1.8090104@redhat.com> <56D467C5.9030402@redhat.com> <56D46C91.6070207@redhat.com> From: Max Reitz Message-ID: <56D46CD3.2040109@redhat.com> Date: Mon, 29 Feb 2016 17:07:47 +0100 MIME-Version: 1.0 In-Reply-To: <56D46C91.6070207@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6G4Ggju51DLxAXnno8MEKPsRULCB75nxL" Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] qcow2: Clarify that compressed cluster offset requires shift List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: mgreger@cinci.rr.com, qemu-block@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6G4Ggju51DLxAXnno8MEKPsRULCB75nxL Content-Type: multipart/mixed; boundary="2FvBSnqX9sD0q0hDKHkIhCu9h1UgUbcJi" From: Max Reitz To: Eric Blake , qemu-devel@nongnu.org Cc: mgreger@cinci.rr.com, qemu-block@nongnu.org Message-ID: <56D46CD3.2040109@redhat.com> Subject: Re: [Qemu-block] [PATCH] qcow2: Clarify that compressed cluster offset requires shift References: <1456758714-12609-1-git-send-email-eblake@redhat.com> <56D466F1.8090104@redhat.com> <56D467C5.9030402@redhat.com> <56D46C91.6070207@redhat.com> In-Reply-To: <56D46C91.6070207@redhat.com> --2FvBSnqX9sD0q0hDKHkIhCu9h1UgUbcJi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29.02.2016 17:06, Eric Blake wrote: > On 02/29/2016 08:46 AM, Max Reitz wrote: >=20 >>>> Compressed Clusters Descriptor (x =3D 62 - (cluster_bits - 8)): >>>> >>>> - Bit 0 - x: Host cluster offset. This is usually _not_ alig= ned to a >>>> - cluster boundary! >>>> + Bit 0 - x: Bits 9-(x+9) of host cluster offset. This is >>> >>> I'd rather use one of "9..(x+9)", "[9, x+9]", "9 - (x+9)", "9=E2=80=94= (x+9)" in >>> order to clarify that this is not a minus but a range. >> >> ...unless, of course, this is actually a byte offset, which it seems t= o >> be, judging from qcow2_get_cluster_offset() (and >> qcow2_decompress_cluster(), as Kevin said on IRC). >=20 > Hmm, then I may be totally wrong. (Serves me right for trying to write = a > spec patch without testing actual behavior). >=20 > At the least, we may want to say that things are usually not aligned to= > even a _sector_ boundary (not just cluster boundary), and also clarify > whether the sector length is truncated or rounded up (zlib doesn't care= > about trailing garbage during decompression, but you DO need to know ho= w > many sectors to read to ensure that you are supplying zlib with trailin= g > garbage, rather than a truncated stream). Yes, I agree. Max --2FvBSnqX9sD0q0hDKHkIhCu9h1UgUbcJi-- --6G4Ggju51DLxAXnno8MEKPsRULCB75nxL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW1GzTAAoJEDuxQgLoOKyt0ccIAJrdA+P59VvJItKr8sjezZA1 LNoYX6aRKhnrKepDlM+/koPhGLx7QtHrnuDoaxUJOHtXy2nZ32CN6yY5Zbqe95TD ayt4/UBir6c9fLvUhnW4FRYuHIPwTY/W65ZnQdGLteSD7VWz8bayNCj/WJIxElMf nLoe+PMTG6KzKkrsRRxheXrJomeVXnO/X5WYcaYJYkPeq+1gu0wEZH0hd3MdYt7q wkeVYdtvotFK2UWsi7cJJ0M/uWBcg468BSQgB+PqZduhBLNAZqCRrakPADge7E6p fGHHYo7+k9nL72Km45C3BPEaranVu5fLzAu2JLPQaEfnI4QhMAF0ldpFqChmHZ4= =vI38 -----END PGP SIGNATURE----- --6G4Ggju51DLxAXnno8MEKPsRULCB75nxL--