From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfWpb-0006bT-7a for qemu-devel@nongnu.org; Thu, 23 May 2013 10:49:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfWpW-0004K7-Kv for qemu-devel@nongnu.org; Thu, 23 May 2013 10:49:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63410) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfWiB-00015p-6m for qemu-devel@nongnu.org; Thu, 23 May 2013 10:41:47 -0400 Date: Thu, 23 May 2013 16:41:43 +0200 From: Kevin Wolf Message-ID: <20130523144142.GG3082@dhcp-200-207.str.redhat.com> References: <5193AB0A.6090500@redhat.com> <20130515155823.GG2858@dhcp-200-207.str.redhat.com> <5193C93C.5060406@redhat.com> <20130516082441.GB2467@dhcp-200-207.str.redhat.com> <51952DE6.9050505@redhat.com> <20130522135305.GA23852@dhcp-200-207.str.redhat.com> <20130523115704.GG9093@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130523115704.GG9093@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] QMP interface for drive-add (or even blockdev-add) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: lcapitulino@redhat.com, armbru@redhat.com, stefanha@redhat.com, qemu-devel@nongnu.org Am 23.05.2013 um 13:57 hat Stefan Hajnoczi geschrieben: > On Wed, May 22, 2013 at 03:53:05PM +0200, Kevin Wolf wrote: > > Am 16.05.2013 um 21:05 hat Eric Blake geschrieben: > > > On 05/16/2013 02:24 AM, Kevin Wolf wrote: > > The other thing that I'm not sure about is whether we should teach QAPI > > to parse certain data structures just into QDicts instead of C structs, > > or if dealing with the big unions inside the block layer actually makes > > sense. > > This is an interesting question. It's very convenient from the code > side - we don't have to worry about laying down a schema. > > However, the point of QAPI is to offer that schema that allows for us to > reason about things like compatibility (hard to sneak in a patch that > modifies the schema, easy to sneak in a patch that modifies block driver > parameter code) and eliminates the boilerplate of type-checking/basic > input validation. > > Even if it requires some effort, I think we should avoid tunneling > schema-less data over QAPI. Note that I'm talking _only_ about the C side here. Everything that goes through QMP is an external API and must described by a schema, I fully agree there. The question is whether QAPI must, after validating the input against the schema, parse it into C structs or whether it should be able to fill QDicts and pass those around. Maybe it's just an unjustified feeling, but a C union of the option structs for all image formats feels very ugly for me, whereas I think a union is perfectly fine in the JSON schema. Kevin