Kevin Wolf <kw...@redhat.com> writes: > 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.
Seconded.