[Top][All Lists]

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

Re: [Qemu-devel] QMP interface for drive-add (or even blockdev-add)

From: Kevin Wolf
Subject: Re: [Qemu-devel] QMP interface for drive-add (or even blockdev-add)
Date: Thu, 23 May 2013 16:41:43 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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.


reply via email to

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