From: Eric Blake <eblake@redhat.com>
To: "Luiz Capitulino" <lcapitulino@redhat.com>,
"Benoît Canet" <benoit.canet@irqsave.net>
Cc: "Markus Armbruster" <armbru@redhat.com>,
"Lluís Vilanova" <vilanova@ac.upc.edu>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v12 0/4] qapi: Allow modularization of QAPI schema files
Date: Tue, 06 May 2014 08:55:52 -0600 [thread overview]
Message-ID: <5368F7F8.3090706@redhat.com> (raw)
In-Reply-To: <20140506092725.4c195cbd@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]
On 05/06/2014 07:27 AM, Luiz Capitulino wrote:
> On Tue, 6 May 2014 15:07:40 +0200
> Benoît Canet <benoit.canet@irqsave.net> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2014-05-06 14:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 13:52 [Qemu-devel] [PATCH v12 0/4] qapi: Allow modularization of QAPI schema files Lluís Vilanova
2014-05-02 13:52 ` [Qemu-devel] [PATCH v12 1/4] qapi: [trivial] Break long command lines Lluís Vilanova
2014-05-02 13:52 ` [Qemu-devel] [PATCH v12 2/4] qapi: [trivial] Do not catch unknown exceptions in "test-qapi.py" Lluís Vilanova
2014-05-02 13:52 ` [Qemu-devel] [PATCH v12 3/4] qapi: Use an explicit input file Lluís Vilanova
2014-05-02 13:52 ` [Qemu-devel] [PATCH v12 4/4] qapi: Add a primitive to include other files from a QAPI schema file Lluís Vilanova
2014-05-05 20:31 ` Luiz Capitulino
2014-05-05 21:15 ` Lluís Vilanova
2014-05-07 18:46 ` Lluís Vilanova
2014-05-07 18:48 ` Lluís Vilanova
2014-05-07 20:44 ` Luiz Capitulino
2014-05-18 11:44 ` Peter Maydell
2014-05-05 18:21 ` [Qemu-devel] [PATCH v12 0/4] qapi: Allow modularization of QAPI schema files Luiz Capitulino
2014-05-07 16:36 ` Luiz Capitulino
2014-05-07 17:07 ` Lluís Vilanova
2014-05-07 17:14 ` Luiz Capitulino
2014-05-07 17:20 ` Lluís Vilanova
2014-05-07 17:23 ` Luiz Capitulino
2014-05-06 13:07 ` Benoît Canet
2014-05-06 13:27 ` Luiz Capitulino
2014-05-06 14:05 ` Benoît Canet
2014-05-06 14:55 ` Eric Blake [this message]
2014-05-06 16:55 ` Luiz Capitulino
2014-05-06 17:11 ` Eric Blake
2014-05-07 19:44 ` Markus Armbruster
2014-05-07 20:01 ` Benoît Canet
2014-05-06 15:02 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5368F7F8.3090706@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=benoit.canet@irqsave.net \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=vilanova@ac.upc.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).