From: Markus Armbruster <armbru@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Michael Roth" <michael.roth@amd.com>
Subject: Re: [PATCH 5/6] qapi: apply schema prefix to QAPI feature enum constants
Date: Thu, 08 Aug 2024 13:48:47 +0200 [thread overview]
Message-ID: <87ed6zxmjk.fsf@pond.sub.org> (raw)
In-Reply-To: <20240801175913.669013-6-berrange@redhat.com> ("Daniel P. Berrangé"'s message of "Thu, 1 Aug 2024 18:59:12 +0100")
Daniel P. Berrangé <berrange@redhat.com> writes:
> This allows us to include multiple QAPI schemas in the same file.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This commit prepends an optional prefix to generated uses of
QAPI_FEATURE_{DEPRECATED,UNSTABLE}.
It touches neither the handwritten definition in include/qapi/util.h,
nor the handwritten uses in qapi/qapi-util.c and
qapi/qobject-output-visitor.c.
Code generated with a prefix will not compile, unless it uses no
features. No biggie, because:
The next commit replaces the handwritten definition (no prefix) by a
generated one (with optional prefix).
Now the handwritten code compiles only because it includes an enum
definition generated without a prefix, namely the main schema's.
Note that the handwritten code continues to work even when you use it
together with some other schema, but only because all the generated
enums assign the same numeric value to the enumeration constants
_DEPRECATED and _UNSTABLE.
While that seems fairly unlikely to break accidentally, it still feels
unnecessarily dirty.
What about generating an enum like this:
typedef enum {
QAPI_FEATURE_DEPRECATED = QAPI_DEPRECATED,
QAPI_FEATURE_UNSTABLE = QAPI_UNSTABLE,
...
} QapiFeature;
where QAPI_DEPRECATED and QAPI_UNSTABLE are defined in qapi/util.h, like
they are before this series.
We can discuss renaming them to QAPI_SPECIAL_FEATURE_DEPRECATED and
_UNSTABLE if you like.
Code referring to special features, i.e. all references before this
series, use the definitions from qapi/util.h.
Code referring to arbitrary, possibly non-special features, i.e. the
references new in this series, use the generated definitions from
qapi/qapi-features.h.
Thoughts?
next prev parent reply other threads:[~2024-08-08 11:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 17:59 [PATCH 0/6] qapi: generalize special features Daniel P. Berrangé
2024-08-01 17:59 ` [PATCH 1/6] qapi: change 'unsigned special_features' to 'uint64_t features' Daniel P. Berrangé
2024-08-05 11:53 ` Markus Armbruster
2024-08-01 17:59 ` [PATCH 2/6] scripts/qapi: rename 'special_features' to 'features' Daniel P. Berrangé
2024-08-05 11:59 ` Markus Armbruster
2024-08-01 17:59 ` [PATCH 3/6] qapi: use "QAPI_FEATURE" as namespace for features Daniel P. Berrangé
2024-08-05 12:01 ` Markus Armbruster
2024-08-01 17:59 ` [PATCH 4/6] qapi: cope with feature names containing a '-' Daniel P. Berrangé
2024-08-05 12:10 ` Markus Armbruster
2024-08-01 17:59 ` [PATCH 5/6] qapi: apply schema prefix to QAPI feature enum constants Daniel P. Berrangé
2024-08-05 12:22 ` Markus Armbruster
2024-08-05 12:33 ` Daniel P. Berrangé
2024-08-05 13:11 ` Markus Armbruster
2024-08-05 13:24 ` Daniel P. Berrangé
2024-08-05 13:54 ` Markus Armbruster
2024-08-05 14:59 ` Markus Armbruster
2024-08-06 17:49 ` Complications due to having multiple QAPI schemas (was: [PATCH 5/6] qapi: apply schema prefix to QAPI feature enum constants) Markus Armbruster
2024-08-08 11:48 ` Markus Armbruster [this message]
2024-08-01 17:59 ` [PATCH 6/6] qapi: expose all schema features to code Daniel P. Berrangé
2024-08-02 13:50 ` Markus Armbruster
2024-08-02 15:43 ` Daniel P. Berrangé
2024-08-08 12:11 ` Markus Armbruster
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=87ed6zxmjk.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/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.