[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management |
Date: |
Thu, 15 Aug 2019 10:00:15 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 |
On 8/15/19 9:44 AM, Maxim Levitsky wrote:
>>>> Does the idea of a union type with a default value for the discriminator
>>>> help? Maybe we have a discriminator which defaults to 'auto', and add a
>>>> union branch 'auto':'any'. During creation, if the "driver":"auto"
>>>> branch is selected (usually implicitly by omitting "driver", but also
>>>> possible explicitly), the creation attempt is rejected as invalid
>>>> regardless of the contents of the remaining 'any'. But during amend
>>>> usage, if the 'auto' branch is selected, we then add in the proper
>>>> "driver":"xyz" and reparse the QAPI object to determine if the remaining
>>>> fields in 'any' still meet the specification for the required driver
>>>> branch.
>>>>
>>>> This idea may still require some tweaks to the QAPI generator, but it's
>>>> the best I can come up with for a way to parse an arbitrary JSON object
>>>> with unknown validation, then reparse it again after adding more
>>>> information that would constrain the parse differently.
>>>
>>> Feels like this would be a lot of code just to allow the client to omit
>>> passing a value that it knows anyway. If this were a human interface, I
>>> could understand the desire to make commands less verbose, but for QMP I
>>> honestly don't see the point when it's not trivial.
>>
>> Seconded.
>
>
> But what about my suggestion of adding something like:
>
> { 'union': 'BlockdevAmendOptions',
>
> 'base': {
> 'node-name': 'str' },
>
> 'discriminator': { 'get_block_driver(node-name)' } ,
Not worth it. It makes the QAPI generator more complex (to invoke
arbitrary code instead of a fixed name) just to avoid a little bit of
complexity in the caller (which is assumed to be a computer, and thus
shouldn't have a hard time providing a sane 'driver' unconditionally).
An HMP wrapper around the QMP command can do whatever magic it needs to
omit driver, but making driver mandatory for QMP is just fine.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-devel] [PATCH 12/13] qemu-img: implement key management, (continued)
[Qemu-devel] [PATCH 13/13] iotests : add tests for encryption key management, Maxim Levitsky, 2019/08/14
Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management, Eric Blake, 2019/08/14
- Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management, Maxim Levitsky, 2019/08/15
- Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management, Kevin Wolf, 2019/08/15
- Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management, Markus Armbruster, 2019/08/15
- Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management, Maxim Levitsky, 2019/08/15
- Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management,
Eric Blake <=
- Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management, Maxim Levitsky, 2019/08/19
- Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management, Markus Armbruster, 2019/08/21
- Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management, Maxim Levitsky, 2019/08/21
Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management, Max Reitz, 2019/08/20
Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management, Daniel P . Berrangé, 2019/08/22