From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCoph-0003Kh-NL for qemu-devel@nongnu.org; Tue, 14 Jun 2016 09:56:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCopf-0003Qa-Oq for qemu-devel@nongnu.org; Tue, 14 Jun 2016 09:56:44 -0400 References: <1465294275-8733-1-git-send-email-berrange@redhat.com> From: Max Reitz Message-ID: <0ba49fee-41ac-82c4-2031-2622ca6c1bec@redhat.com> Date: Tue, 14 Jun 2016 15:56:30 +0200 MIME-Version: 1.0 In-Reply-To: <1465294275-8733-1-git-send-email-berrange@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7oFb0iinDiH5vvlchCgAb7MEklt8FeXW8" Subject: Re: [Qemu-devel] [PATCH v1 0/6] Report format specific info for LUKS block driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Cc: qemu-block@nongnu.org, Kevin Wolf , Markus Armbruster , Michael Roth , Eric Blake This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7oFb0iinDiH5vvlchCgAb7MEklt8FeXW8 From: Max Reitz To: "Daniel P. Berrange" , qemu-devel@nongnu.org Cc: qemu-block@nongnu.org, Kevin Wolf , Markus Armbruster , Michael Roth , Eric Blake Message-ID: <0ba49fee-41ac-82c4-2031-2622ca6c1bec@redhat.com> Subject: Re: [PATCH v1 0/6] Report format specific info for LUKS block driver References: <1465294275-8733-1-git-send-email-berrange@redhat.com> In-Reply-To: <1465294275-8733-1-git-send-email-berrange@redhat.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 07.06.2016 12:11, Daniel P. Berrange wrote: > The 'qemu-img info' tool has ability to print format specific > information, eg with qcow2 it reports two extra items: >=20 > $ qemu-img info ~/VirtualMachines/demo.qcow2 > image: /home/berrange/VirtualMachines/demo.qcow2 > file format: qcow2 > virtual size: 3.0G (3221225472 bytes) > disk size: 140K > cluster_size: 65536 > Format specific information: > compat: 0.10 > refcount bits: 16 >=20 >=20 > This is not currently wired up for the LUKS driver. This patch > series adds that support so that we can report useful data about > the LUKS volume such as the crypto algorithm choices, key slot > usage and other volume metadata. >=20 > The first patch extends the crypto API to allow querying of the > format specific metadata >=20 > The second patches extends the block API to allow the LUKS driver > to report the format specific metadata. >=20 > $ qemu-img info ~/VirtualMachines/demo.luks > image: /home/berrange/VirtualMachines/demo.luks > file format: luks > virtual size: 98M (102760448 bytes) > disk size: 100M > encrypted: yes > Format specific information: > cipher-alg: aes-128 > cipher-mode: xts > ivgen-alg: plain64 > hash-alg: sha1 > payload-offset: 2097152 > master-key-iters: 142375 > uuid: 6ddee74b-3a22-408c-8909-6789d4fa2594 > slots: > [0]: > active: true > iters: 572706 > stripes: 4000 > key-offset: 8 > [1]: > active: false > iters: 0 > stripes: 4000 > key-offset: 264 > [2]: > active: false > iters: 0 > stripes: 4000 > key-offset: 520 > [3]: > active: false > iters: 0 > stripes: 4000 > key-offset: 776 > [4]: > active: false > iters: 0 > stripes: 4000 > key-offset: 1032 > [5]: > active: false > iters: 0 > stripes: 4000 > key-offset: 1288 > [6]: > active: false > iters: 0 > stripes: 4000 > key-offset: 1544 > [7]: > active: false > iters: 0 > stripes: 4000 > key-offset: 1800 >=20 > The remaining 4 patches are improvements to QAPI and the core > block layer to fix a problem whereby struct fields are output > in (apparently) random ordering. This is because the QAPI type > is converted into a QObject for pretty-printing, thus throwing > away any struct field ordering information. >=20 > To address this I created a new TextOutputVisitor which can > directly pretty-print QAPI types. I then changed the code > generator to create qapi_stringify_TYPENAME() methods for > all QAPI types. Finally I changed the block layer over to > use this stringify approach instead. General nagging: This new approach no longer replaces dashes with spaces in the key names. Is it worth doing something about this? Max --7oFb0iinDiH5vvlchCgAb7MEklt8FeXW8 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 iQEcBAEBCAAGBQJXYA0OAAoJEDuxQgLoOKytIQoH/j6eOBk21teAZt+eS0v8QEMu UuWsV1LDHi1I52GKsIif1PqU0oO0/OVW1AoAq9n0REUuDl/P/hJRbp5xUMuI7ZYY C5i8h9LTbRy3kSCuP/LcCySPMZa7ILs+4L3CRcVmXrOPWL8JehYOQE1dyTZFSB+z dgUIBmK3CQueXod2wkRZ0fkoANtFjkCNJlsErUvr9yQZYZcCkRtn+s49DZnCSHSb 613AsFrNSOkitYkgJNcMtCdrXcB2HO989xha6Rq9pWYbJdyntJtLtiPUMTaMyVOa nsu0J+Sd25mToxciLcPooDllZiS5eR+kOKPBdvUfZFCcQHqkmMcAGXqOoEVDjP4= =oKQJ -----END PGP SIGNATURE----- --7oFb0iinDiH5vvlchCgAb7MEklt8FeXW8--