Re: [Qemu-devel] [PATCH RFC v5 30/32] qapi: New QMP command query-qmp-schema for QMP introspection

[Markus Armbruster]

Michael Roth  writes:

> Quoting Markus Armbruster (2015-09-07 05:16:41)
>> qapi/introspect.json defines the introspection schema.  It's designed
>> for QMP introspection, but should do for similar uses, such as QGA.
>> 
>> The introspection schema does not reflect all the rules and
>> restrictions that apply to QAPI schemata.  A valid QAPI schema has an
>> introspection value conforming to the introspection schema, but the
>> converse is not true.
>> 
>> Introspection lowers away a number of schema details, and makes
>> implicit things explicit:
>> 
>> * The built-in types are declared with their JSON type.
>> 
>>   TODO Should we map all the integer types to just int?
>> 
>> * Implicit type definitions are made explicit, and given
>>   auto-generated names:
>> 
>>   - Array types, named by appending "List" to the name of their
>> element type, like in generated C.
>> 
>>   - The enumeration types implicitly defined by simple union types,
>> named by appending "Kind" to the name of their simple union type,
>> like in generated C.
>> 
>>   - Types that don't occur in generated C.  Their names start with ':'
>> so they don't clash with the user's names.
>> 
>> * All type references are by name.
>> 
>> * The struct and union types are generalized into an object type.
>> 
>> * Base types are flattened.
>> 
>> * Commands take a single argument and return a single result.
>> 
>>   Dictionary argument or list result is an implicit type definition.
>> 
>>   The empty object type is used when a command takes no arguments or
>>   produces no results.
>> 
>>   The argument is always of object type, but the introspection schema
>>   doesn't reflect that.
>> 
>>   The 'gen': false directive is omitted as implementation detail.
>> 
>>   The 'success-response' directive is omitted as well for now, even
>>   though it's not an implementation detail, because it's not used by
>>   QMP.
>> 
>> * Events carry a single data value.
>> 
>>   Implicit type definition and empty object type use, just like for
>>   commands.
>> 
>>   The value is of object type, but the introspection schema doesn't
>>   reflect that.
>> 
>> * Types not used by commands or events are omitted.
>> 
>>   Indirect use counts as use.
>> 
>> * Optional members have a default, which can only be null right now
>> 
>>   Instead of a mandatory "optional" flag, we have an optional default.
>>   No default means mandatory, default null means optional without
>>   default value.  Non-null is available for optional with default
>>   (possible future extension).
>> 
>> * Clients should *not* look up types by name, because type names are
>>   not ABI.  Look up the command or event you're interested in, then
>>   follow the references.
>> 
>>   TODO Should we hide the type names to eliminate the temptation?
>> 
>> New generator scripts/qapi-introspect.py computes an introspection
>> value for its input, and generates a C variable holding it.
>> 
>> It can generate awfully long lines.  Marked TODO.
>
> Would be good if we could get this is for initial merge to help
> with debugging if anything pops up.

Unlikely, to be honest.  Patches depending on this series have been
piling up.  I'd be okay with delaying follow-up QAPI work some more, but
not work on other subsystems, especially not user-visible goodies.

Work-arounds:

* Take the C string from qmp-introspect.c, unquote it to get actual
  string contents, feed it to your favourite JSON pretty printer.  I've
  used Python's pprint.

* Run query-qmp-schema, feed the result to your favourite JSON pretty
  printer.

* Likewise, using the QMP monitor's integrated pretty printer, e.g.
  with --qmp-pretty.

>> A new test-qmp-input-visitor test case feeds its result for both
>> tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a
>> QmpInputVisitor to verify it actually conforms to the schema.
>> 
>> New QMP command query-qmp-schema takes its return value from that
>> variable.  Its reply is some 85KiBytes for me right now.
>> 
>> If this turns out to be too much, we have a couple of options:
>> 
>> * We can use shorter names in the JSON.  Not the QMP style.
>> 
>> * Optionally return the sub-schema for commands and events given as
>>   arguments.
>> 
>>   Right now qmp_query_schema() sends the string literal computed by
>>   qmp-introspect.py.  To compute sub-schema at run time, we'd have to
>>   duplicate parts of qapi-introspect.py in C.  Unattractive.
>> 
>> * Let clients cache the output of query-qmp-schema.
>> 
>>   It changes only on QEMU upgrades, i.e. rarely.  Provide a command
>>   query-qmp-schema-hash.  Clients can have a cache indexed by hash,
>>   and re-query the schema only when they don't have it cached.  Even
>>   simpler: put the hash in the QMP greeting.
>
> Would probably be easier for management to build up their own structure
> for querying caps, so I think a computed hash seems best. But I don't
> think either is something that couldn't be 

Re: [Qemu-devel] [PATCH RFC v5 30/32] qapi: New QMP command query-qmp-schema for QMP introspection

[Daniel P. Berrange]

On Fri, Sep 11, 2015 at 09:02:15AM +0200, Markus Armbruster wrote:
> Michael Roth  writes:
> 
> > Quoting Markus Armbruster (2015-09-07 05:16:41)
> >> A new test-qmp-input-visitor test case feeds its result for both
> >> tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a
> >> QmpInputVisitor to verify it actually conforms to the schema.
> >> 
> >> New QMP command query-qmp-schema takes its return value from that
> >> variable.  Its reply is some 85KiBytes for me right now.
> >> 
> >> If this turns out to be too much, we have a couple of options:
> >> 
> >> * We can use shorter names in the JSON.  Not the QMP style.
> >> 
> >> * Optionally return the sub-schema for commands and events given as
> >>   arguments.
> >> 
> >>   Right now qmp_query_schema() sends the string literal computed by
> >>   qmp-introspect.py.  To compute sub-schema at run time, we'd have to
> >>   duplicate parts of qapi-introspect.py in C.  Unattractive.
> >> 
> >> * Let clients cache the output of query-qmp-schema.
> >> 
> >>   It changes only on QEMU upgrades, i.e. rarely.  Provide a command
> >>   query-qmp-schema-hash.  Clients can have a cache indexed by hash,
> >>   and re-query the schema only when they don't have it cached.  Even
> >>   simpler: put the hash in the QMP greeting.
> >
> > Would probably be easier for management to build up their own structure
> > for querying caps, so I think a computed hash seems best. But I don't
> > think either is something that couldn't be added later if need be.
> 
> I also think a hash is the way to go, and I'd like to provide one early,
> but I don't want to delay this series for it.

FWIW, libvirt already caches the results of its query of QEMU and will
only re-query QEMU if the timestamp of the QEMU binary on disk has
changed, or if libvirt itself has changed.  Also when querying the QEMU
capabilities there are quite a few commands we run, we want to cache
the full set, not just query-qmp-schema, so we can avoid launching QEMU
at all. o at least from Libvirt's POV, I don't think we have a need for
a hash of query-qmp-schema.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH RFC v5 30/32] qapi: New QMP command query-qmp-schema for QMP introspection

[Markus Armbruster]

"Daniel P. Berrange"  writes:

> On Fri, Sep 11, 2015 at 09:02:15AM +0200, Markus Armbruster wrote:
>> Michael Roth  writes:
>> 
>> > Quoting Markus Armbruster (2015-09-07 05:16:41)
>> >> A new test-qmp-input-visitor test case feeds its result for both
>> >> tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a
>> >> QmpInputVisitor to verify it actually conforms to the schema.
>> >> 
>> >> New QMP command query-qmp-schema takes its return value from that
>> >> variable.  Its reply is some 85KiBytes for me right now.
>> >> 
>> >> If this turns out to be too much, we have a couple of options:
>> >> 
>> >> * We can use shorter names in the JSON.  Not the QMP style.
>> >> 
>> >> * Optionally return the sub-schema for commands and events given as
>> >>   arguments.
>> >> 
>> >>   Right now qmp_query_schema() sends the string literal computed by
>> >>   qmp-introspect.py.  To compute sub-schema at run time, we'd have to
>> >>   duplicate parts of qapi-introspect.py in C.  Unattractive.
>> >> 
>> >> * Let clients cache the output of query-qmp-schema.
>> >> 
>> >>   It changes only on QEMU upgrades, i.e. rarely.  Provide a command
>> >>   query-qmp-schema-hash.  Clients can have a cache indexed by hash,
>> >>   and re-query the schema only when they don't have it cached.  Even
>> >>   simpler: put the hash in the QMP greeting.
>> >
>> > Would probably be easier for management to build up their own structure
>> > for querying caps, so I think a computed hash seems best. But I don't
>> > think either is something that couldn't be added later if need be.
>> 
>> I also think a hash is the way to go, and I'd like to provide one early,
>> but I don't want to delay this series for it.
>
> FWIW, libvirt already caches the results of its query of QEMU and will
> only re-query QEMU if the timestamp of the QEMU binary on disk has
> changed, or if libvirt itself has changed.  Also when querying the QEMU
> capabilities there are quite a few commands we run, we want to cache
> the full set, not just query-qmp-schema, so we can avoid launching QEMU
> at all. o at least from Libvirt's POV, I don't think we have a need for
> a hash of query-qmp-schema.

Noted.

Re: [Qemu-devel] [PATCH RFC v5 30/32] qapi: New QMP command query-qmp-schema for QMP introspection

[Michael Roth]

Quoting Markus Armbruster (2015-09-07 05:16:41)
> qapi/introspect.json defines the introspection schema.  It's designed
> for QMP introspection, but should do for similar uses, such as QGA.
> 
> The introspection schema does not reflect all the rules and
> restrictions that apply to QAPI schemata.  A valid QAPI schema has an
> introspection value conforming to the introspection schema, but the
> converse is not true.
> 
> Introspection lowers away a number of schema details, and makes
> implicit things explicit:
> 
> * The built-in types are declared with their JSON type.
> 
>   TODO Should we map all the integer types to just int?
> 
> * Implicit type definitions are made explicit, and given
>   auto-generated names:
> 
>   - Array types, named by appending "List" to the name of their
> element type, like in generated C.
> 
>   - The enumeration types implicitly defined by simple union types,
> named by appending "Kind" to the name of their simple union type,
> like in generated C.
> 
>   - Types that don't occur in generated C.  Their names start with ':'
> so they don't clash with the user's names.
> 
> * All type references are by name.
> 
> * The struct and union types are generalized into an object type.
> 
> * Base types are flattened.
> 
> * Commands take a single argument and return a single result.
> 
>   Dictionary argument or list result is an implicit type definition.
> 
>   The empty object type is used when a command takes no arguments or
>   produces no results.
> 
>   The argument is always of object type, but the introspection schema
>   doesn't reflect that.
> 
>   The 'gen': false directive is omitted as implementation detail.
> 
>   The 'success-response' directive is omitted as well for now, even
>   though it's not an implementation detail, because it's not used by
>   QMP.
> 
> * Events carry a single data value.
> 
>   Implicit type definition and empty object type use, just like for
>   commands.
> 
>   The value is of object type, but the introspection schema doesn't
>   reflect that.
> 
> * Types not used by commands or events are omitted.
> 
>   Indirect use counts as use.
> 
> * Optional members have a default, which can only be null right now
> 
>   Instead of a mandatory "optional" flag, we have an optional default.
>   No default means mandatory, default null means optional without
>   default value.  Non-null is available for optional with default
>   (possible future extension).
> 
> * Clients should *not* look up types by name, because type names are
>   not ABI.  Look up the command or event you're interested in, then
>   follow the references.
> 
>   TODO Should we hide the type names to eliminate the temptation?
> 
> New generator scripts/qapi-introspect.py computes an introspection
> value for its input, and generates a C variable holding it.
> 
> It can generate awfully long lines.  Marked TODO.

Would be good if we could get this is for initial merge to help
with debugging if anything pops up.

> 
> A new test-qmp-input-visitor test case feeds its result for both
> tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a
> QmpInputVisitor to verify it actually conforms to the schema.
> 
> New QMP command query-qmp-schema takes its return value from that
> variable.  Its reply is some 85KiBytes for me right now.
> 
> If this turns out to be too much, we have a couple of options:
> 
> * We can use shorter names in the JSON.  Not the QMP style.
> 
> * Optionally return the sub-schema for commands and events given as
>   arguments.
> 
>   Right now qmp_query_schema() sends the string literal computed by
>   qmp-introspect.py.  To compute sub-schema at run time, we'd have to
>   duplicate parts of qapi-introspect.py in C.  Unattractive.
> 
> * Let clients cache the output of query-qmp-schema.
> 
>   It changes only on QEMU upgrades, i.e. rarely.  Provide a command
>   query-qmp-schema-hash.  Clients can have a cache indexed by hash,
>   and re-query the schema only when they don't have it cached.  Even
>   simpler: put the hash in the QMP greeting.

Would probably be easier for management to build up their own structure
for querying caps, so I think a computed hash seems best. But I don't
think either is something that couldn't be added later if need be.

> 
> Signed-off-by: Markus Armbruster 
> ---
>  .gitignore  |   1 +
>  Makefile|   9 +-
>  Makefile.objs   |   4 +-
>  docs/qapi-code-gen.txt  | 232 +++-
>  monitor.c   |  15 ++
>  qapi-schema.json|   3 +
>  qapi/introspect.json| 276 
> 
>  qmp-commands.hx |  17 ++
>  scripts/qapi-introspect.py  | 177 +++
>  scripts/qapi.py   

Re: [Qemu-devel] [PATCH RFC v5 30/32] qapi: New QMP command query-qmp-schema for QMP introspection

[Markus Armbruster]

Eric Blake  writes:

> On 09/07/2015 04:16 AM, Markus Armbruster wrote:
>> qapi/introspect.json defines the introspection schema.  It's designed
>> for QMP introspection, but should do for similar uses, such as QGA.
>> 
>> The introspection schema does not reflect all the rules and
>> restrictions that apply to QAPI schemata.  A valid QAPI schema has an
>> introspection value conforming to the introspection schema, but the
>> converse is not true.
>> 
>> Introspection lowers away a number of schema details, and makes
>> implicit things explicit:
>> 
>
>> +##
>> +# @SchemaInfoObjectMember
>> +#
>> +# An object member.
>> +#
>> +# @name: the member's name, as defined in the QAPI schema.
>> +#
>> +# @type: the name of the member's type.
>> +#
>> +# @default: #optional default when used as command parameter.
>> +#   If absent, the parameter is mandatory.
>> +#   If present, the value must be null.  The parameter is
>> +#   optional, and behavior when it's missing is not specified
>> +#   here.
>> +#   Future extension: if present and non-null, the parameter
>> +#   is optional, and defaults to this value.
>> +#
>
>> +##
>> +# @SchemaInfoObjectVariant
>> +#
>> +# The variant members for a value of the type tag.
>> +#
>> +# @case: a value of the type tag.
>> +#
>> +# @type: the name of the object type that provides the variant members
>> +# when the type tag has value @case.
>
> You aren't consistent on whether secondary lines describing the same
> @variable are indented or flush left.  I don't care enough to hold up
> review, but just pointing it out in case you want to reflow some text.

I'm happy to do small, local, obviously safe changes.

> I've finished re-reading 31 and 32, and double-checking that the
> combined text of all three patches together makes sense as a whole.
> Looks like we're ready for this series to come out of RFC soon :)
>
> And I'll start rebasing and posting my followup patches that have
> already been on list...

Thanks!

Re: [Qemu-devel] [PATCH RFC v5 30/32] qapi: New QMP command query-qmp-schema for QMP introspection

[Markus Armbruster]

Eric Blake  writes:

> On 09/07/2015 04:16 AM, Markus Armbruster wrote:
>> qapi/introspect.json defines the introspection schema.  It's designed
>> for QMP introspection, but should do for similar uses, such as QGA.
>> 
>> The introspection schema does not reflect all the rules and
>> restrictions that apply to QAPI schemata.  A valid QAPI schema has an
>> introspection value conforming to the introspection schema, but the
>> converse is not true.
>> 
>
>>   Right now qmp_query_schema() sends the string literal computed by
>
> Should this be spelled qmp_query_qmp_schema()? [1]

Yes.

>>   qmp-introspect.py.  To compute sub-schema at run time, we'd have to
>>   duplicate parts of qapi-introspect.py in C.  Unattractive.
>
>
>> Signed-off-by: Markus Armbruster 
>> ---
>
> Changes I noticed from v4:
> Simple unions work now.
> Documentation improvements.
> Rename to query-qmp-schema (except perhaps where I marked [1], but I'm
> not too fussed with either spelling).
> Use of self._member for internal fields.
>
> Reviewed-by: Eric Blake 

Thanks!

Re: [Qemu-devel] [PATCH RFC v5 30/32] qapi: New QMP command query-qmp-schema for QMP introspection

[Eric Blake]

On 09/07/2015 04:16 AM, Markus Armbruster wrote:
> qapi/introspect.json defines the introspection schema.  It's designed
> for QMP introspection, but should do for similar uses, such as QGA.
> 
> The introspection schema does not reflect all the rules and
> restrictions that apply to QAPI schemata.  A valid QAPI schema has an
> introspection value conforming to the introspection schema, but the
> converse is not true.
> 
> Introspection lowers away a number of schema details, and makes
> implicit things explicit:
> 

> +##
> +# @SchemaInfoObjectMember
> +#
> +# An object member.
> +#
> +# @name: the member's name, as defined in the QAPI schema.
> +#
> +# @type: the name of the member's type.
> +#
> +# @default: #optional default when used as command parameter.
> +#   If absent, the parameter is mandatory.
> +#   If present, the value must be null.  The parameter is
> +#   optional, and behavior when it's missing is not specified
> +#   here.
> +#   Future extension: if present and non-null, the parameter
> +#   is optional, and defaults to this value.
> +#

> +##
> +# @SchemaInfoObjectVariant
> +#
> +# The variant members for a value of the type tag.
> +#
> +# @case: a value of the type tag.
> +#
> +# @type: the name of the object type that provides the variant members
> +# when the type tag has value @case.

You aren't consistent on whether secondary lines describing the same
@variable are indented or flush left.  I don't care enough to hold up
review, but just pointing it out in case you want to reflow some text.

I've finished re-reading 31 and 32, and double-checking that the
combined text of all three patches together makes sense as a whole.
Looks like we're ready for this series to come out of RFC soon :)

And I'll start rebasing and posting my followup patches that have
already been on list...

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH RFC v5 30/32] qapi: New QMP command query-qmp-schema for QMP introspection

[Eric Blake]

On 09/07/2015 04:16 AM, Markus Armbruster wrote:
> qapi/introspect.json defines the introspection schema.  It's designed
> for QMP introspection, but should do for similar uses, such as QGA.
> 
> The introspection schema does not reflect all the rules and
> restrictions that apply to QAPI schemata.  A valid QAPI schema has an
> introspection value conforming to the introspection schema, but the
> converse is not true.
> 

>   Right now qmp_query_schema() sends the string literal computed by

Should this be spelled qmp_query_qmp_schema()? [1]

>   qmp-introspect.py.  To compute sub-schema at run time, we'd have to
>   duplicate parts of qapi-introspect.py in C.  Unattractive.


> Signed-off-by: Markus Armbruster 
> ---

Changes I noticed from v4:
Simple unions work now.
Documentation improvements.
Rename to query-qmp-schema (except perhaps where I marked [1], but I'm
not too fussed with either spelling).
Use of self._member for internal fields.

Reviewed-by: Eric Blake 

> 
> --- a/monitor.c
> +++ b/monitor.c
> @@ -74,6 +74,7 @@
>  #include "block/qapi.h"
>  #include "qapi/qmp-event.h"
>  #include "qapi-event.h"
> +#include "qmp-introspect.h"
>  #include "sysemu/block-backend.h"
>  
>  /* for hmp_info_irq/pic */
> @@ -928,6 +929,20 @@ EventInfoList *qmp_query_events(Error **errp)
>  return ev_list;
>  }
>  
> +/*
> + * Minor hack: generated marshalling suppressed for this command
> + * ('gen': false in the schema) so we can parse the JSON string
> + * directly into QObject instead of first parsing it with
> + * visit_type_SchemaInfoList() into a SchemaInfoList, then marshal it
> + * to QObject with generated output marshallers, every time.  Instead,
> + * we do it in test-qmp-input-visitor.c, just to make sure
> + * qapi-introspect.py's output actually conforms to the schema.
> + */
> +static void qmp_query_schema(QDict *qdict, QObject **ret_data, Error **errp)

[1]

> +++ b/qmp-commands.hx
> @@ -2193,6 +2193,23 @@ EQMP
>  },
>  
>  SQMP
> +query-qmp-schema
> +
> +
> +Return the QMP wire schema.  The returned value is a json-array of
> +named schema entities.  Entities are commands, events and various
> +types.  See docs/qapi-code-gen.txt for information on their structure
> +and intended use.
> +
> +EQMP
> +
> +{
> +.name   = "query-qmp-schema",
> +.args_type  = "",
> +.mhandler.cmd_new = qmp_query_schema,

[1] qmp_query_qmp_schema might match naming conventions better.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH RFC v5 30/32] qapi: New QMP command query-qmp-schema for QMP introspection

[Markus Armbruster]

qapi/introspect.json defines the introspection schema.  It's designed
for QMP introspection, but should do for similar uses, such as QGA.

The introspection schema does not reflect all the rules and
restrictions that apply to QAPI schemata.  A valid QAPI schema has an
introspection value conforming to the introspection schema, but the
converse is not true.

Introspection lowers away a number of schema details, and makes
implicit things explicit:

* The built-in types are declared with their JSON type.

  TODO Should we map all the integer types to just int?

* Implicit type definitions are made explicit, and given
  auto-generated names:

  - Array types, named by appending "List" to the name of their
element type, like in generated C.

  - The enumeration types implicitly defined by simple union types,
named by appending "Kind" to the name of their simple union type,
like in generated C.

  - Types that don't occur in generated C.  Their names start with ':'
so they don't clash with the user's names.

* All type references are by name.

* The struct and union types are generalized into an object type.

* Base types are flattened.

* Commands take a single argument and return a single result.

  Dictionary argument or list result is an implicit type definition.

  The empty object type is used when a command takes no arguments or
  produces no results.

  The argument is always of object type, but the introspection schema
  doesn't reflect that.

  The 'gen': false directive is omitted as implementation detail.

  The 'success-response' directive is omitted as well for now, even
  though it's not an implementation detail, because it's not used by
  QMP.

* Events carry a single data value.

  Implicit type definition and empty object type use, just like for
  commands.

  The value is of object type, but the introspection schema doesn't
  reflect that.

* Types not used by commands or events are omitted.

  Indirect use counts as use.

* Optional members have a default, which can only be null right now

  Instead of a mandatory "optional" flag, we have an optional default.
  No default means mandatory, default null means optional without
  default value.  Non-null is available for optional with default
  (possible future extension).

* Clients should *not* look up types by name, because type names are
  not ABI.  Look up the command or event you're interested in, then
  follow the references.

  TODO Should we hide the type names to eliminate the temptation?

New generator scripts/qapi-introspect.py computes an introspection
value for its input, and generates a C variable holding it.

It can generate awfully long lines.  Marked TODO.

A new test-qmp-input-visitor test case feeds its result for both
tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a
QmpInputVisitor to verify it actually conforms to the schema.

New QMP command query-qmp-schema takes its return value from that
variable.  Its reply is some 85KiBytes for me right now.

If this turns out to be too much, we have a couple of options:

* We can use shorter names in the JSON.  Not the QMP style.

* Optionally return the sub-schema for commands and events given as
  arguments.

  Right now qmp_query_schema() sends the string literal computed by
  qmp-introspect.py.  To compute sub-schema at run time, we'd have to
  duplicate parts of qapi-introspect.py in C.  Unattractive.

* Let clients cache the output of query-qmp-schema.

  It changes only on QEMU upgrades, i.e. rarely.  Provide a command
  query-qmp-schema-hash.  Clients can have a cache indexed by hash,
  and re-query the schema only when they don't have it cached.  Even
  simpler: put the hash in the QMP greeting.

Signed-off-by: Markus Armbruster 
---
 .gitignore  |   1 +
 Makefile|   9 +-
 Makefile.objs   |   4 +-
 docs/qapi-code-gen.txt  | 232 +++-
 monitor.c   |  15 ++
 qapi-schema.json|   3 +
 qapi/introspect.json| 276 
 qmp-commands.hx |  17 ++
 scripts/qapi-introspect.py  | 177 +++
 scripts/qapi.py |  13 +-
 tests/.gitignore|   1 +
 tests/Makefile  |  10 +-
 tests/qapi-schema/alternate-good.out|   1 +
 tests/qapi-schema/args-member-array.out |   1 +
 tests/qapi-schema/comments.out  |   1 +
 tests/qapi-schema/empty.out |   1 +
 tests/qapi-schema/enum-empty.out|   1 +
 tests/qapi-schema/event-case.out|   1 +
 tests/qapi-schema/flat-union-reverse-define.out |   1 +
 tests/qapi-schema/ident-with-escape.out |   1 +