From: Markus Armbruster <armbru@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 00/13] qapi: add #if pre-processor conditions to generated code (part 3)
Date: Tue, 18 Dec 2018 19:19:16 +0100 [thread overview]
Message-ID: <87lg4mbsuz.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20181216140902.23986-1-marcandre.lureau@redhat.com> ("Marc-André Lureau"'s message of "Sun, 16 Dec 2018 18:08:49 +0400")
Marc-André Lureau <marcandre.lureau@redhat.com> writes:
> Hi,
>
> The thrid and last part (of "[PATCH v2 00/54] qapi: add #if
> pre-processor conditions to generated code") is about adding schema
> conditions based on the target.
>
> For now, the qapi code is compiled in common objects (common to all
> targets). This makes it impossible to add #if TARGET_ARM for example.
>
> The patch "RFC: qapi: learn to split the schema by 'top-unit'"
> proposes to split the schema by "top-unit", so that generated code can
> be built either in common objects or per-target. That patch is a bit
> rough, I would like to get some feedback about the approach before
> trying to improve it. The following patches demonstrate usage of
> target-based #if conditions, and getting rid of the
> qmp_unregister_command() hack.
Lovely except for the 'top-unit' feature. I believe the existing
modules can do the job. Quoting my "[PATCH v2 00/29] Modularize
generated QAPI code":
Related: Marc-André's 'unit' pragma proposal. That's a different
way to split off parts of the generated code, motivated by the
desire to use poisoned identifiers such as TARGET_I386. I noted in
my review of v3 that I "can either accept it, or come up with a
better solution." This is my attempt at a better solution. It's a
bit more ambitious, and thus more useful (I hope). The pragma has
one theoretical advantage, though: you can modularize the generated
output in different ways than the input. The patches using don't do
that, however.
I'm going to post RFC patches that show how to do a target-dependent
module. Then we can discuss the two approaches.
prev parent reply other threads:[~2018-12-18 18:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-16 14:08 [Qemu-devel] [PATCH 00/13] qapi: add #if pre-processor conditions to generated code (part 3) Marc-André Lureau
2018-12-16 14:08 ` [Qemu-devel] [PATCH 01/13] build-sys: move qmp-introspect per target Marc-André Lureau
2018-12-17 7:06 ` Markus Armbruster
2018-12-16 14:08 ` [Qemu-devel] [PATCH 02/13] qapi-commands: don't initialize command list in qmp_init_marshall() Marc-André Lureau
2018-12-16 14:08 ` [Qemu-devel] [PATCH 03/13] qapi-commands: rename init_marshal() to register_commands() Marc-André Lureau
2018-12-16 14:08 ` [Qemu-devel] [PATCH 04/13] RFC: qapi: learn to split the schema by 'top-unit' Marc-André Lureau
2018-12-16 14:08 ` [Qemu-devel] [PATCH 05/13] qapi: add a top-unit 'target' schema Marc-André Lureau
2018-12-16 14:08 ` [Qemu-devel] [PATCH 06/13] qapi: make rtc-reset-reinjection and SEV depend on TARGET_I386 Marc-André Lureau
2018-12-16 14:08 ` [Qemu-devel] [PATCH 07/13] qapi: make s390 commands depend on TARGET_S390X Marc-André Lureau
2018-12-18 18:00 ` Markus Armbruster
2018-12-16 14:08 ` [Qemu-devel] [PATCH 08/13] target.json: add a note about query-cpu* not being s390x-specific Marc-André Lureau
2018-12-16 14:08 ` [Qemu-devel] [PATCH 09/13] qapi: make query-gic-capabilities depend on TARGET_ARM Marc-André Lureau
2018-12-16 14:08 ` [Qemu-devel] [PATCH 10/13] qapi: make query-cpu-model-expansion depend on s390 or x86 Marc-André Lureau
2018-12-18 12:35 ` Markus Armbruster
2018-12-16 14:09 ` [Qemu-devel] [PATCH 11/13] qapi: make query-cpu-definitions depend on specific targets Marc-André Lureau
2018-12-18 18:01 ` Markus Armbruster
2018-12-16 14:09 ` [Qemu-devel] [PATCH 12/13] qapi: remove qmp_unregister_command() Marc-André Lureau
2018-12-16 14:09 ` [Qemu-devel] [PATCH 13/13] qapi: move RTC_CHANGE to the target schema Marc-André Lureau
2018-12-18 18:19 ` Markus Armbruster [this message]
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=87lg4mbsuz.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.