10d4d997f8
...or an array of dictionaries. Although we have to cater to existing commands, returning a non-dictionary means the command is not extensible (no new name/value pairs can be added if more information must be returned in parallel). By making the whitelist explicit, any new command that falls foul of this practice will have to be self-documenting, which will encourage developers to either justify the action or rework the design to use a dictionary after all. It's a little bit sloppy that we share a single whitelist among three clients (it's too permissive for each). If this is a problem, a future patch could tighten things by having the generator take the whitelist as an argument (as in scripts/qapi-commands.py --legacy-returns=...), or by having the generator output C code that requires explicit use of the whitelist (as in: #ifndef FROBNICATE_LEGACY_RETURN_OK # error Command 'frobnicate' should return a dictionary #endif then having the callers define appropriate macros). But until we need such fine-grained separation (if ever), this patch does the job just fine. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
12 lines
421 B
JSON
12 lines
421 B
JSON
# we enforce that 'returns' be a dict or array of dict unless whitelisted
|
|
{ 'command': 'human-monitor-command',
|
|
'data': {'command-line': 'str', '*cpu-index': 'int'},
|
|
'returns': 'str' }
|
|
{ 'enum': 'TpmModel', 'data': [ 'tpm-tis' ] }
|
|
{ 'command': 'query-tpm-models', 'returns': ['TpmModel'] }
|
|
{ 'command': 'guest-get-time',
|
|
'returns': 'int' }
|
|
|
|
{ 'command': 'no-way-this-will-get-whitelisted',
|
|
'returns': [ 'int' ] }
|