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 :|
