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

[Kevin Wolf]

Am 23.05.2013 um 14:08 hat Anthony Liguori geschrieben:
> Kevin Wolf <address@hidden> writes:
> 
> > Am 22.05.2013 um 18:14 hat Anthony Liguori geschrieben:
> >> Kevin Wolf <address@hidden> writes:
> >> > 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.
> 
> There are two things here: the schema and the generated code.  The
> generated code can and should live in the module.
> 
> But the schema always stays the same.
> 
> Think of the schema like kernel headers.  The kernel headers are always
> fixed regardless of what kernel modules are loaded or how the kernel is
> configured.
> 
> > then we don't need introspection at all. There's no user for it then.
> 
> Introspection is not the right approach to feature discovery.  The
> schema does answer the question of what features are enabled, it just
> answers the question of what the signature of the methods are.

You can see it like this. Then, as I said, it's totally useless, because
nobody has ever asked this question. The context in which libvirt wants
to use it is feature discovery. If we don't support that, then there's
no reason to provide introspection at all.

libvirt already knows how to use features. It must know it, just parsing
the schema doesn't automagically give you libvirt code, so someone must
have coded the libvirt side of things. The interesting part is whether a
given interface is available on this specific qemu binary.

> > 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,
> 
> query-commands serves that purpose.

It solves a subset of this problem. Optional fields can be added as
arguments or to returned structs, enums can be extended, and so far
we're having a hard time making use of it because the client can't
discover it.

> > 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.
> 
> Let's consider a real example.  It sounds like you have something in
> mind, can you be more specific?

Not a very specific one, it's just that the more I discuss about things
like blockdev-add, the more I get the impression that there is an awful
lot of information to query. Each image format can provide different
options, for creating images and for opening them, and some of them may
be enums that could be extended and whose values must be queried etc.

Schema introspection allows you to have one single way to check for all
optional fields, enum values, union branches. The other way is to have a
separate command for each of them.

Basically instead of query-enum(Qcow2PreallocationType) you get
query-qcow2-prellocation-types(). You can imagine how the set of
commands grows once you start doing things this way.

When I discussed with Eric (who is one of the few actual consumers of
the API), he preferred introspection of a dynamic schema as well,
compared to many separate query-* commands.

Kevin