From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53869) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu5Ch-0004LK-Lj for qemu-devel@nongnu.org; Tue, 02 Jul 2013 14:21:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uu5Cd-0001l5-UB for qemu-devel@nongnu.org; Tue, 02 Jul 2013 14:21:27 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:53308) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu5Cd-0001kz-QC for qemu-devel@nongnu.org; Tue, 02 Jul 2013 14:21:23 -0400 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 2 Jul 2013 19:21:23 +0100 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 9E1D138C8045 for ; Tue, 2 Jul 2013 14:21:20 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r62ILLtN272258 for ; Tue, 2 Jul 2013 14:21:21 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r62ILJFp020058 for ; Tue, 2 Jul 2013 15:21:21 -0300 From: Anthony Liguori In-Reply-To: <51D3035A.1060605@redhat.com> References: <1371644677-11041-1-git-send-email-akong@redhat.com> <878v1pqak4.fsf@codemonkey.ws> <51D2F1B3.1080903@redhat.com> <20130702153945.GZ2524@redhat.com> <51D3035A.1060605@redhat.com> Date: Tue, 02 Jul 2013 13:21:13 -0500 Message-ID: <877gh8j012.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH] full introspection support for QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , "Daniel P. Berrange" Cc: armbru@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, qiaonuohan@cn.fujitsu.com, pbonzini@redhat.com, Amos Kong Eric Blake writes: > On 07/02/2013 09:39 AM, Daniel P. Berrange wrote: >>>> Maybe I'm being too meta here, but why not just return qapi-schema.json >>>> as a string and call it as day? >>> >>> Because qapi-schema.json requires further parsing. For example, how is >>> a client supposed to know that '*foo':'int' means that there is an >>> argument named 'foo' but it is optional? The rule of thumb with QMP is >>> that if you have to post-process JSON output, then the JSON was not >>> designed correctly. >> >> Arguably that rule of thumb would apply equally to the QEMU >> build scripts which already parse qapi-schema.json. It could >> be possible to normalize qapi-schema.json somewhat to remove >> this 2-stage parsing if we went down this route. > > Indeed, I wouldn't mind a one-time pass over qapi-schema.json to make it > follow a more rigid format if that made it easier to use it as-is with > less post-processing. It won't be very nice to backport such a > conversion, but I don't know how much distros are planning on > backporting introspection in the first place. We consume the schema in QEMU. No reason for us to consume it in a different format than libvirt. We're all after the same thing. Regards, Anthony Liguori > >> >> I'm finding it hard to clearly see what the 2 different proposed >> data formats look like against each other. Can someone give some >> examples, showing the data that would need to be parsed in each >> format, for a couple of examples. > > My proposal (but not quite what was implemented in _this_ version of > Amos' patch) has been: > > qapi-schema.json: > > { 'command': 'add_client', > 'data': { 'protocol': 'str', 'fdname': 'str', '*skipauth': 'bool', > '*tls': 'bool' } } > > My proposal: > > > => { "execute": "query-qmp-schema", > "arguments": { "name": "add_client" } } > <= { "return": [ > { "name": "add_client", > "type": "command", > "data": [ > { "name": "protocol", > "type": "str" }, > { "name": "fdname", > "type": "str" }, > { "name": "skipauth", > "type": "bool", > "optional": true }, > { "name": "tls", > "type": "bool", > "optional": true } > ] } ] } > > Note that one other benefit of breaking out "optional" into its own dict > member: we are free to expand the dict to add new members, such as a > '*default':'str' member (present when "optional":true, and with the > stringized value of the default value used if "name" is not present). > Of course, to be able to express a default value, we already have to > modify the syntax stored in qapi-schema.json in the first place, which > takes us back to the argument of a one-time conversion of the .json file > to actually use a more formal typing system in the first place. I really think that we want schema introspection to return the exact content of qapi-schema.json. I don't think we need an overly verbose schema though and I don't really understand why { 'name': 'tls', 'type': 'bool', 'optional': true } is better than { '*name': 'bool' } Regards, Anthony Liguori > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org