From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAJbf-0004Et-TY for qemu-devel@nongnu.org; Tue, 07 Jun 2016 12:11:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAJbb-00021g-Rt for qemu-devel@nongnu.org; Tue, 07 Jun 2016 12:11:55 -0400 References: <1465294275-8733-1-git-send-email-berrange@redhat.com> <1465294275-8733-3-git-send-email-berrange@redhat.com> <5756E9E8.8000908@redhat.com> <20160607155134.GR20196@redhat.com> From: Eric Blake Message-ID: <5756F243.3070504@redhat.com> Date: Tue, 7 Jun 2016 10:11:47 -0600 MIME-Version: 1.0 In-Reply-To: <20160607155134.GR20196@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TGKtebpUsnOo5I4M9VuOU3hlhwqW4GBiw" Subject: Re: [Qemu-devel] [PATCH v1 2/6] block: export LUKS specific data to qemu-img info List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Kevin Wolf , Max Reitz , Markus Armbruster , Michael Roth This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TGKtebpUsnOo5I4M9VuOU3hlhwqW4GBiw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/07/2016 09:51 AM, Daniel P. Berrange wrote: >> >> Missing documentation, but why do you need it, since it is identical t= o >> QCryptoBlockInfoLUKSSlot in the previous patch? >> >=20 > Essentially yes, and this is something I meant to mention in > the cover letter. >=20 > I wasn't really sure on the best approach to take here. I > could certainly re-use the QCrypto QAPI object by doing >=20 > { 'union': 'ImageInfoSpecific', > 'data': { > 'qcow2': 'ImageInfoSpecificQCow2', > 'vmdk': 'ImageInfoSpecificVmdk', > 'luks': 'QCryptoBlockInfoLUKS', > } } >=20 > I was not sure if that was a good idea or whether it is better > to have isolation between the crypto layer and block layer, as > safety net in case we need them to diverge. If we need to diverge in the future, then we can create the new type at that time. We intentionally made introspection hide type names, so that we are not held hostage by type name changes, and so that splitting types to add functionality to one but not all uses is safe. > The main thing was > whether the data we report from the block driver will need to > include extra stuff not present in QCryptoBlockInfoLUKS, perhaps > related to the backing file/format. That may be an argument for making one type the base class for the other, rather than a complete reimplementation. >=20 > I guess another option would be for ImageInfoSpecificLUKS > to sub-class QCryptoBlockInfoLUKS in that case. Yep, just what I said :) --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --TGKtebpUsnOo5I4M9VuOU3hlhwqW4GBiw 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXVvJDAAoJEKeha0olJ0Nq4NAIAJJl51b0YxKAnipxG029BoX+ IfZ5Nvler8moNgJWAuUP9RDEHQikkjH1/ggFBwOMLxnCIw3WYMiWQt+mr6Do4Axw lM+d7qz5vg2j0wpgrB19ji8YiBY6OYLcqR3hYzPyN1M3cyy/4Cg0840kLGUyi10J v3uNQ2COqgtlUVI3TnMYjB/BZjOo4zPHmaLWIuVe2I7DHGo/jvtNKXK5n50AtEsw OmXWbgqVaoBTLbX+LSKKij24cuV6bVApWsKAGjT+KRLKqif2GR7TowZ6O5Z2ReV9 Dh3nGWLWdTnCr4+WArPhLL1mhfnugKMMLe6qkkXWRbW8pzMd3/mfHsQ7XFu3ibo= =GMC+ -----END PGP SIGNATURE----- --TGKtebpUsnOo5I4M9VuOU3hlhwqW4GBiw--