qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v12 0/4] qapi: Allow modularization of QAPI sche


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v12 0/4] qapi: Allow modularization of QAPI schema files
Date: Tue, 06 May 2014 08:55:52 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 05/06/2014 07:27 AM, Luiz Capitulino wrote:
> On Tue, 6 May 2014 15:07:40 +0200
> Benoît Canet <address@hidden> wrote:
> 
>> I am trying to use this series to modularise the block API.
>>
>> Here are my finding.
>>
>> I tried to make a qmp/block.json including VM state related API.
>> block.json include a qmp/block-core.json containing only true block stuff.
>>
>> When generating and compiling block-core.json to link it with qemu-nbd
>> I saw that some of the block stuff needed ErrorClass so I went the route
>> of creating a qmp/common.json containing ErrorClass.
>>
>> common.json being included in block-core.json and in qapi-schema.json it
>> quickly lead some code being generated in double and the compilation to 
>> choke.
>>
>> What do you think would be the best solution to fix this ?
>> (Fix the generator ? Make include ignore second inclusion of the same file ?)
> 
> Make qapi-schema.json a sort of master file and include everything?

Won't cut it, if we want to support a subset of files in other contexts.
 You either have to do:

qemu-schema.json:
  include common
  include block
  include other

qemu-block:
  include common
  include block

where block does not work in isolation, and has to be wrapped; but now
we have two different wrappers depending on the two different clients
that want a different subset.  Or you do:

qemu-schema.json:
  include common
  include block
  include other
block.json:
  include common

now block.json is standalone, and qemu-schema.json ends up including
common through two different paths.


> 
> Eventually, we might want to have if/defs and whatnot. But having a master
> file seems a reasonable first step to me. I actually thought this was the
> intention. Unless I got it wrong, of course.

Ifdefs may be a bit much.  If we add them, then we can worry about
explicit include guards, the same as the C preprocessor.  But for now,
I'd be perfectly fine with a followup patch that includes a file's
contents exactly once, no matter how many times it is included (that is,
act as if include guards were implicitly present, since we lack
conditionals, so include files are currently idempotent).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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