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 ;) -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
