qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v6 02/18] block: add ability to set a prefix for


From: Daniel P. Berrange
Subject: Re: [Qemu-block] [PATCH v6 02/18] block: add ability to set a prefix for opt names
Date: Wed, 26 Apr 2017 15:13:29 +0100
User-agent: Mutt/1.7.1 (2016-10-04)

On Wed, Apr 26, 2017 at 09:12:06AM -0500, Eric Blake wrote:
> On 04/26/2017 08:50 AM, Daniel P. Berrange wrote:
> > On Wed, Apr 26, 2017 at 08:28:04AM -0500, Eric Blake wrote:
> >> On 04/25/2017 10:38 AM, Daniel P. Berrange wrote:
> >>> When integrating the crypto support with qcow/qcow2, we don't
> >>> want to use the bare LUKS option names "hash-alg", "key-secret",
> >>> etc. We want to namespace them "luks-hash-alg", "luks-key-secret"
> >>> so that they don't clash with any general qcow options at a later
> >>> date.
> 
> >> Is this still needed, given your cover letter said you reworked things
> >> to use a nested struct?  I'm still not convinced we need the complexity
> >> of two different prefixes if we can instead reuse a common structure.
> > 
> > Yes, we still need this at the QemuOpts level.  We have the general
> > purpose luks driver that has opts directly in the top level QAPI block
> > driver options, vs the qcow2 integration, which now has the encryption
> > options in a nested struct/union, rather than having an option prefix
> > in the QAPI member names.
> 
> Fair enough.
> 
> > 
> > At the QemuOpts level, this mean that the option names have changed
> > from being 'luks-key-secret', 'aes-key-secret', to be "encrypt.key-secret"
> 
> But you'll want to update the commit message to match your new planned
> names ;)

Hah, opps :-)


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]