From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfBh0-0002LK-GM for qemu-devel@nongnu.org; Wed, 22 May 2013 12:15:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfBgz-0007h6-4l for qemu-devel@nongnu.org; Wed, 22 May 2013 12:15:10 -0400 Received: from e23smtp03.au.ibm.com ([202.81.31.145]:41284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfBgy-0007gX-K3 for qemu-devel@nongnu.org; Wed, 22 May 2013 12:15:09 -0400 Received: from /spool/local by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 May 2013 02:06:31 +1000 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [9.190.235.152]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id EFB202BB0023 for ; Thu, 23 May 2013 02:14:59 +1000 (EST) Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4MG0gSC13893806 for ; Thu, 23 May 2013 02:00:42 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4MGExuM020793 for ; Thu, 23 May 2013 02:14:59 +1000 From: Anthony Liguori In-Reply-To: <20130522144448.GC23852@dhcp-200-207.str.redhat.com> References: <20130522134007.GA2051@t430s.nay.redhat.com> <20130522144448.GC23852@dhcp-200-207.str.redhat.com> Date: Wed, 22 May 2013 11:14:46 -0500 Message-ID: <87fvxfkn49.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] RFC: Full introspection support for QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , Amos Kong Cc: lcapitulino@redhat.com, Ronen Hod , qemu-devel , Markus Armbruster Kevin Wolf 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