From: Anthony Liguori <aliguori@us.ibm.com>
To: Kevin Wolf <kwolf@redhat.com>, Amos Kong <akong@redhat.com>
Cc: lcapitulino@redhat.com, Ronen Hod <rhod@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] RFC: Full introspection support for QMP
Date: Wed, 22 May 2013 11:14:46 -0500 [thread overview]
Message-ID: <87fvxfkn49.fsf@codemonkey.ws> (raw)
In-Reply-To: <20130522144448.GC23852@dhcp-200-207.str.redhat.com>
Kevin Wolf <kwolf@redhat.com> 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
next prev parent reply other threads:[~2013-05-22 16:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-22 13:40 [Qemu-devel] RFC: Full introspection support for QMP Amos Kong
2013-05-22 14:44 ` Kevin Wolf
2013-05-22 16:14 ` Anthony Liguori [this message]
2013-05-23 8:18 ` Kevin Wolf
2013-05-23 12:08 ` Anthony Liguori
2013-05-23 12:40 ` Luiz Capitulino
2013-05-23 12:52 ` Anthony Liguori
2013-05-23 12:54 ` Kevin Wolf
2013-05-23 13:52 ` Anthony Liguori
2013-05-23 14:17 ` Eric Blake
2013-05-23 14:29 ` Kevin Wolf
2013-05-22 17:56 ` Luiz Capitulino
2013-05-23 12:58 ` Eric Blake
2013-06-07 10:12 ` [Qemu-devel] RFC: Full introspection support for QMP (with draft patch) Amos Kong
2013-06-07 10:17 ` Amos Kong
2013-06-14 9:52 ` Amos Kong
2013-06-14 10:59 ` Eric Blake
2013-06-14 11:09 ` Eric Blake
2013-06-18 12:21 ` Amos Kong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fvxfkn49.fsf@codemonkey.ws \
--to=aliguori@us.ibm.com \
--cc=akong@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rhod@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).