[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: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management |
Date: |
Thu, 15 Aug 2019 11:10:39 +0200 |
User-agent: |
Mutt/1.11.3 (2019-02-01) |
Am 14.08.2019 um 23:08 hat Eric Blake geschrieben:
> On 8/14/19 3:22 PM, Maxim Levitsky wrote:
>
> > This is an issue that was raised today on IRC with Kevin Wolf. Really thanks
> > for the idea!
> >
> > We agreed that this new qmp interface should take the same options as
> > blockdev-create does, however since we want to be able to edit the
> > encryption
> > slots separately, this implies that we sort of need to allow this on
> > creation
> > time as well.
> >
> > Also the BlockdevCreateOptions is a union, which is specialized by the
> > driver name
> > which is great for creation, but for update, the driver name is already
> > known,
> > and thus the user should not be forced to pass it again.
> > However qmp doesn't seem to support union type guessing based on actual
> > fields
> > given (this might not be desired either), which complicates this somewhat.
>
> 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.
Kevin
signature.asc
Description: PGP signature
- [Qemu-devel] [PATCH 11/13] block/qcow2: implement the encryption key managment, (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 <=
- 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, 2019/08/15
- 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