aboutsummaryrefslogtreecommitdiff
path: root/tests/qapi-schema/missing-comma-list.err
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2015-05-04 09:05:23 -0600
committerMarkus Armbruster <armbru@redhat.com>2015-05-05 18:39:01 +0200
commit10d4d997f86cf2a4ce89145df5658952d5722e56 (patch)
tree011d73266eda7d953f4105a16d7cafa574edc91c /tests/qapi-schema/missing-comma-list.err
parentc9e0a798691d8c45747b082206e789c8f50523c9 (diff)
qapi: Whitelist commands that don't return dictionary
...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>
Diffstat (limited to 'tests/qapi-schema/missing-comma-list.err')
0 files changed, 0 insertions, 0 deletions