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

[Anthony Liguori <aliguori@us.ibm.com>]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 22.05.2013 um 18:14 hat Anthony Liguori geschrieben:
>> Kevin Wolf <kwolf@redhat.com> 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.

> 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.

> 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.

> 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?

Regards,

Anthony Liguori

>
> Kevin