[Qemu-devel] [PATCH for-3.0] qapi: Make 'allow-oob' optional in SchemaInfoCommand

Markus Armbruster posted 1 patch 5 years, 9 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20180718090557.17248-1-armbru@redhat.com
Test checkpatch passed
Test docker-mingw@fedora passed
Test docker-quick@centos7 passed
qapi/introspect.json       |  6 +++---
scripts/qapi/introspect.py | 10 +++++-----
2 files changed, 8 insertions(+), 8 deletions(-)
[Qemu-devel] [PATCH for-3.0] qapi: Make 'allow-oob' optional in SchemaInfoCommand
Posted by Markus Armbruster 5 years, 9 months ago
Making 'allow-oob' optional in SchemaInfoCommand permits omitting it
in the common case.  Shrinks query-qmp-schema's output from 122.1KiB
to 118.6KiB for me.

Note that out-of-band execution is still experimental (you have to
configure the monitor with x-oob=on to use it).

Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 qapi/introspect.json       |  6 +++---
 scripts/qapi/introspect.py | 10 +++++-----
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/qapi/introspect.json b/qapi/introspect.json
index c7f67b7d78..137b39b992 100644
--- a/qapi/introspect.json
+++ b/qapi/introspect.json
@@ -259,8 +259,8 @@
 #
 # @ret-type: the name of the command's result type.
 #
-# @allow-oob: whether the command allows out-of-band execution.
-#             (Since: 2.12)
+# @allow-oob: whether the command allows out-of-band execution,
+#             defaults to false (Since: 2.12)
 #
 # TODO: @success-response (currently irrelevant, because it's QGA, not QMP)
 #
@@ -268,7 +268,7 @@
 ##
 { 'struct': 'SchemaInfoCommand',
   'data': { 'arg-type': 'str', 'ret-type': 'str',
-            'allow-oob': 'bool' } }
+            '*allow-oob': 'bool' } }
 
 ##
 # @SchemaInfoEvent:
diff --git a/scripts/qapi/introspect.py b/scripts/qapi/introspect.py
index 70ca5dd876..189a4edaba 100644
--- a/scripts/qapi/introspect.py
+++ b/scripts/qapi/introspect.py
@@ -184,11 +184,11 @@ const QLitObject %(c_name)s = %(c_string)s;
                       success_response, boxed, allow_oob, allow_preconfig):
         arg_type = arg_type or self._schema.the_empty_object_type
         ret_type = ret_type or self._schema.the_empty_object_type
-        self._gen_qlit(name, 'command',
-                       {'arg-type': self._use_type(arg_type),
-                        'ret-type': self._use_type(ret_type),
-                        'allow-oob': allow_oob},
-                       ifcond)
+        obj = {'arg-type': self._use_type(arg_type),
+               'ret-type': self._use_type(ret_type) }
+        if allow_oob:
+            obj['allow-oob'] = allow_oob
+        self._gen_qlit(name, 'command', obj, ifcond)
 
     def visit_event(self, name, info, ifcond, arg_type, boxed):
         arg_type = arg_type or self._schema.the_empty_object_type
-- 
2.17.1


Re: [Qemu-devel] [PATCH for-3.0] qapi: Make 'allow-oob' optional in SchemaInfoCommand
Posted by Peter Xu 5 years, 9 months ago
On Wed, Jul 18, 2018 at 11:05:57AM +0200, Markus Armbruster wrote:
> Making 'allow-oob' optional in SchemaInfoCommand permits omitting it
> in the common case.  Shrinks query-qmp-schema's output from 122.1KiB
> to 118.6KiB for me.
> 
> Note that out-of-band execution is still experimental (you have to
> configure the monitor with x-oob=on to use it).
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>

Reviewed-by: Peter Xu <peterx@redhat.com>

Regards,

-- 
Peter Xu

Re: [Qemu-devel] [PATCH for-3.0] qapi: Make 'allow-oob' optional in SchemaInfoCommand
Posted by Eric Blake 5 years, 9 months ago
On 07/18/2018 04:05 AM, Markus Armbruster wrote:
> Making 'allow-oob' optional in SchemaInfoCommand permits omitting it
> in the common case.  Shrinks query-qmp-schema's output from 122.1KiB
> to 118.6KiB for me.
> 
> Note that out-of-band execution is still experimental (you have to
> configure the monitor with x-oob=on to use it).
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---

I see you have already posted the pull request, but the idea makes sense 
to me. In general, making what was previously always output now be 
optional can risk confusing a client that depends on the value being 
present; but since allow-oob has not always been present, and since it 
is still gated by x-oob=on, any sane client using OOB can easily be 
coded to treat an absent indication as not allowing oob for that 
particular command.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org