qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Kevin Wolf <kwolf@redhat.com>, Max Reitz <mreitz@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Michael Roth <mdroth@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v1 2/6] block: export LUKS specific data to qemu-img info
Date: Tue, 7 Jun 2016 10:11:47 -0600	[thread overview]
Message-ID: <5756F243.3070504@redhat.com> (raw)
In-Reply-To: <20160607155134.GR20196@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

On 06/07/2016 09:51 AM, Daniel P. Berrange wrote:

>>
>> Missing documentation, but why do you need it, since it is identical to
>> QCryptoBlockInfoLUKSSlot in the previous patch?
>>

> 
> Essentially yes, and this is something I meant to mention in
> the cover letter.
> 
> I wasn't really sure on the best approach to take here. I
> could certainly re-use the QCrypto QAPI object by doing
> 
> { 'union': 'ImageInfoSpecific',
>   'data': {
>       'qcow2': 'ImageInfoSpecificQCow2',
>       'vmdk': 'ImageInfoSpecificVmdk',
>       'luks': 'QCryptoBlockInfoLUKS',
>   } }
> 
> 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.

> 
> I guess another option would be for ImageInfoSpecificLUKS
> to sub-class QCryptoBlockInfoLUKS in that case.

Yep, just what I said :)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2016-06-07 16:11 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-07 10:11 [Qemu-devel] [PATCH v1 0/6] Report format specific info for LUKS block driver Daniel P. Berrange
2016-06-07 10:11 ` [Qemu-devel] [PATCH v1 1/6] crypto: add support for querying parameters for block encryption Daniel P. Berrange
2016-06-07 14:17   ` Eric Blake
2016-06-07 10:11 ` [Qemu-devel] [PATCH v1 2/6] block: export LUKS specific data to qemu-img info Daniel P. Berrange
2016-06-07 15:36   ` Eric Blake
2016-06-07 15:51     ` Daniel P. Berrange
2016-06-07 16:11       ` Eric Blake [this message]
2016-06-07 10:11 ` [Qemu-devel] [PATCH v1 3/6] qapi: assert that visitor impls have required callbacks Daniel P. Berrange
2016-06-07 15:40   ` Eric Blake
2016-06-07 15:46     ` Daniel P. Berrange
2016-06-07 10:11 ` [Qemu-devel] [PATCH v1 4/6] qapi: add a text output visitor for pretty printing types Daniel P. Berrange
2016-06-07 16:09   ` Eric Blake
2016-06-07 16:20     ` Daniel P. Berrange
2016-06-07 16:40       ` Eric Blake
2016-06-07 16:45         ` Daniel P. Berrange
2016-06-07 10:11 ` [Qemu-devel] [PATCH v1 5/6] qapi: generate a qapi_stringify_TYPENAME method for all types Daniel P. Berrange
2016-06-07 16:23   ` Eric Blake
2016-06-07 10:11 ` [Qemu-devel] [PATCH v1 6/6] block: convert to use qapi_stringify_ImageInfoSpecific Daniel P. Berrange
2016-06-07 16:59   ` Eric Blake
2016-06-07 12:04 ` [Qemu-devel] [PATCH v1 0/6] Report format specific info for LUKS block driver Eric Blake
2016-06-07 14:35   ` Daniel P. Berrange
2016-06-14 13:56 ` Max Reitz
2016-06-14 14:05   ` Daniel P. Berrange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5756F243.3070504@redhat.com \
    --to=eblake@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).