On 15.02.20 15:51, Markus Armbruster wrote: > Review of this patch led to a lengthy QAPI schema design discussion. > Let me try to condense it into a concrete proposal. > > This is about the QAPI schema, and therefore about QMP. The > human-friendly interface is out of scope. Not because it's not > important (it clearly is!), only because we need to *focus* to have a > chance at success. > > I'm going to include a few design options. I'll mark them "Option:". > > The proposed "amend" interface takes a specification of desired state, > and figures out how to get from here to there by itself. LUKS keyslots > are one part of desired state. > > We commonly have eight LUKS keyslots. Each keyslot is either active or > inactive. An active keyslot holds a secret. > > Goal: a QAPI type for specifying desired state of LUKS keyslots. > > Proposal: > > { 'enum': 'LUKSKeyslotState', > 'data': [ 'active', 'inactive' ] } > > { 'struct': 'LUKSKeyslotActive', > 'data': { 'secret': 'str', > '*iter-time': 'int } } > > { 'struct': 'LUKSKeyslotInactive', > 'data': { '*old-secret': 'str' } } > > { 'union': 'LUKSKeyslotAmend', > 'base': { '*keyslot': 'int', > 'state': 'LUKSKeyslotState' } > 'discriminator': 'state', > 'data': { 'active': 'LUKSKeyslotActive', > 'inactive': 'LUKSKeyslotInactive' } }
Looks OK to me. The only thing is that @old-secret kind of works as an address, just like @keyslot, so it might also make sense to me to put @keyslot/@old-secret into a union in the base structure. (One of the problems that come to mind with that approach is that not specifying either of @old-secret or @keyslot has different meanings for activating/inactivating a keyslot: When activating it, it means “The first unused one”; when deactivating it, it’s just an error because it doesn’t really mean anything.) *shrug* Max
signature.asc
Description: OpenPGP digital signature