Re: [Qemu-devel] RFC: Full introspection support for QMP

[Kevin Wolf]

Am 22.05.2013 um 18:14 hat Anthony Liguori geschrieben:
> Kevin Wolf <address@hidden> writes:
> 
> > Am 22.05.2013 um 15:40 hat Amos Kong geschrieben:
> >> Hi all,
> >> 
> >> We already have query-command-line-options to query details of command-line
> >> options. As we discussed in the list, we also need full introspection of 
> >> QMP
> >> (command). The qmp-events also need to be dumped, we can define events in
> >> qai-schema.json. We can also dump QMP errors in future if it's needed.
> >> 
> >> Command name: query-qmp-schema
> >> Return: returns the contents of qapi-schema.json in json format.
> >> 
> >> Solution to query json content from C code:
> >>   qapi-schema.json is processed by qapi python scripts to generate C
> >>   files, I found the content is good enough for Libvirt to know the
> >>   QMP command schema. We can change qapi scripts to generate a talbe/list
> >>   to record the raw string, then we can return the raw string in
> >>   qmp_query_qmp_schema().
> >
> > Yes, the schema as defined in qapi-schema.json should be good to be sent
> > over the wire.
> >
> > Maybe we should already now consider that we'll want to have a dynamic
> > schema eventually: Depending on which modules are compiled in (or even
> > which modules are loaded when we go forward with shared libraries), some
> > types, commands or enum values may be available or not.
> >
> > For example, libvirt wants to query which block drivers it can use. It
> > doesn't really matter for which drivers we had the source initially, but
> > only which drivers are compiled in (possibly loaded) and can actually be
> > used.
> 
> The schema is the wrong place to discover this.
> 
> Loading a module wouldn't add an enumeration value.  The enumeration
> values are fixed.
> 
> We should introduce commands to query this kind of information.
> 
> Schema introspection is primarily useful for dynamic languages to
> autogenerate bindings.  It's not terribly useful for query
> capabilities/features.

Then you won't get real modularity. It means that all modules must
already be known during the build time, and if they aren't available
(because they weren't built or aren't loaded) you include them anyway,
some parts of them are a static part of the core. You don't get fully
rid of modules by not linking their object file in, but you always have
the QAPI part left over.

It also makes the schema totally useless. If you can't use it to tell
which commands this qemu can execute and which it can't, then we don't
need introspection at all. There's no user for it then.

We can have hundreds of individual query commands like you suggest
(query-qcow2-creation-option-values, yay!) or we do the modularity
thing and the schema introspection properly and make it dynamic. I
prefer the latter.

Kevin