qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] RFC: Full introspection support for QMP
Date: Wed, 22 May 2013 11:14:46 -0500
User-agent: Notmuch/0.15.2+77~g661dcf8 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

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.

Regards,

Anthony Liguori

>> By default, return the complete schema in one go.
>> 
>> And support to query of unknown type in new command.
>>   -> { "execute": "query-qmp-schema" "arguments": { "command": 
>> "query-status" }}
>>   <- { "return" : "data": { "command': "query-status", "returns": 
>> "StatusInfo" }}
>>   -> { "execute": "query-qmp-schema" "arguments": { "type": "StatusInfo" }}
>>   <- { "return" : "data": { "type": "StatusInfo", "data": {"running": "bool",
>>                             "singlestep": "bool", "status": "RunState"} }
>>   -> { "execute": "query-qmp-schema" "arguments": { "event": 
>> "RX-FILTER-CHANGE" }}
>
> Maybe a (shortened) example for the complete schema version? I assume it
> will be just an array of the structs you showed here?
>
> Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]