From: Markus Armbruster <armbru@redhat.com>
To: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
qemu-devel@nongnu.org,
"Richard Henderson" <richard.henderson@linaro.org>,
"Anton Johansson" <anjo@rev.ng>,
"Daniel P. Berrangé" <berrange@redhat.com>
Subject: Re: [RFC PATCH v3 13/14] qemu/target_info: Add target_aarch64() helper
Date: Tue, 22 Apr 2025 08:04:41 +0200 [thread overview]
Message-ID: <87tt6g91fq.fsf@pond.sub.org> (raw)
In-Reply-To: <3242cee6-7485-4958-a198-38d0fc68e8cd@linaro.org> (Pierrick Bouvier's message of "Sat, 19 Apr 2025 08:52:02 -0700")
Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:
[...]
> At this point, I would like to focus on having a first version of TargetInfo API, and not reviewing any other changes, as things may be modified, and they would need to be reviewed again. It's hard to follow the same abstraction done multiple times in multiple series.
>
> Regarding your proposal for target_system_arch(), I understand that you tried to reuse the existing SysEmuTarget, which was a good intention.
> However, I don't think we should use any string compare for this (which qemu_api_parse does). It has several flaws:
qemu_api_parse()? Do you mean qapi_enum_parse()?
> - The most important one: it can fail (what if -1 is returned?). Enums can be guaranteed and exhaustive at compile time.
> - It's slower than having the current arch directly known at compile time.
> As well, since SysEmuTarget is a generated enum, it makes it much harder to follow code IMHO.
> QAPI requires those things to be defined from a json file for external usage, but it's not a good reason for being forced to use it in all the codebase as the only possible abstraction.
>
> To have something fast and infallible, we can adopt this solution:
>
> In target_info.h:
>
> /* Named TargetArch to not clash with poisoned TARGET_X */
> typedef enum TargetArch {
> TARGET_ARCH_AARCH64,
> TARGET_ARCH_ALPHA,
> TARGET_ARCH_ARM,
> TARGET_ARCH_AVR,
> TARGET_ARCH_HPPA,
> TARGET_ARCH_I386,
> TARGET_ARCH_LOONGARCH64,
> TARGET_ARCH_M68K,
> TARGET_ARCH_MICROBLAZE,
> TARGET_ARCH_MICROBLAZEEL,
> TARGET_ARCH_MIPS,
> TARGET_ARCH_MIPS64,
> TARGET_ARCH_MIPS64EL,
> TARGET_ARCH_MIPSEL,
> TARGET_ARCH_OR1K,
> TARGET_ARCH_PPC,
> TARGET_ARCH_PPC64,
> TARGET_ARCH_RISCV32,
> TARGET_ARCH_RISCV64,
> TARGET_ARCH_RX,
> TARGET_ARCH_S390X,
> TARGET_ARCH_SH4,
> TARGET_ARCH_SH4EB,
> TARGET_ARCH_SPARC,
> TARGET_ARCH_SPARC64,
> TARGET_ARCH_TRICORE,
> TARGET_ARCH_X86_64,
> TARGET_ARCH_XTENSA,
> TARGET_ARCH_XTENSAEB,
> } TargetArch;
Effectively duplicates generated enum SysEmuTarget. Can you explain why
that's useful?
>
> typedef struct TargetInfo {
> ...
> TargetArch target_arch;
> ...
> }
>
> static inline target_arch() {
> return target_info()->target_arch;
> }
>
> static inline target_aarch64() {
> return target_arch() == TARGET_ARCH_AARCH64;
> }
>
>
> In target_info-stub.c:
>
> #ifdef TARGET_AARCH64
> # define TARGET_ARCH TARGET_ARCH_AARCH64
> #elif TARGET_ARCH_ALPHA
> # define TARGET_ARCH TARGET_ARCH_ALPHA
> ...
> #endif
>
> static const TargetInfo target_info_stub = {
> ...
> .target_arch = TARGET_ARCH;
> ...
> }
next prev parent reply other threads:[~2025-04-22 6:05 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-18 17:28 [RFC PATCH v3 00/14] single-binary: Make hw/arm/ common Philippe Mathieu-Daudé
2025-04-18 17:28 ` [RFC PATCH v3 01/14] qapi: Rename TargetInfo structure as BinaryTargetInfo Philippe Mathieu-Daudé
2025-04-18 17:33 ` Philippe Mathieu-Daudé
2025-04-21 15:47 ` Richard Henderson
2025-04-22 5:55 ` Markus Armbruster
2025-04-22 7:35 ` Philippe Mathieu-Daudé
2025-04-22 9:10 ` Markus Armbruster
2025-04-22 9:18 ` Philippe Mathieu-Daudé
2025-04-22 12:29 ` BALATON Zoltan
2025-04-22 17:37 ` Pierrick Bouvier
2025-04-18 17:28 ` [RFC PATCH v3 02/14] qemu: Convert target_name() to TargetInfo API Philippe Mathieu-Daudé
2025-04-21 15:56 ` Richard Henderson
2025-04-22 7:44 ` Philippe Mathieu-Daudé
2025-04-18 17:28 ` [RFC PATCH v3 03/14] system/vl: Filter machine list available for a particular target binary Philippe Mathieu-Daudé
2025-04-19 0:57 ` Pierrick Bouvier
2025-04-18 17:28 ` [RFC PATCH v3 04/14] hw/arm: Register TYPE_TARGET_ARM/AARCH64_MACHINE QOM interfaces Philippe Mathieu-Daudé
2025-04-19 0:58 ` Pierrick Bouvier
2025-04-18 17:28 ` [RFC PATCH v3 05/14] hw/core: Allow ARM/Aarch64 binaries to use the 'none' machine Philippe Mathieu-Daudé
2025-04-19 0:59 ` Pierrick Bouvier
2025-04-18 17:29 ` [RFC PATCH v3 06/14] hw/arm: Filter machine types for qemu-system-arm/aarch64 binaries Philippe Mathieu-Daudé
2025-04-19 0:59 ` Pierrick Bouvier
2025-04-18 17:29 ` [RFC PATCH v3 07/14] meson: Prepare to accept per-binary TargetInfo structure implementation Philippe Mathieu-Daudé
2025-04-19 0:59 ` Pierrick Bouvier
2025-04-18 17:29 ` [RFC PATCH v3 08/14] config/target: Implement per-binary TargetInfo structure (ARM, AARCH64) Philippe Mathieu-Daudé
2025-04-19 1:00 ` Pierrick Bouvier
2025-04-18 17:29 ` [RFC PATCH v3 09/14] hw/arm/aspeed: Build objects once Philippe Mathieu-Daudé
2025-04-18 17:29 ` [RFC PATCH v3 10/14] hw/arm/raspi: " Philippe Mathieu-Daudé
2025-04-18 17:29 ` [RFC PATCH v3 11/14] hw/core/machine: Allow dynamic registration of valid CPU types Philippe Mathieu-Daudé
2025-04-19 1:16 ` Pierrick Bouvier
2025-04-19 1:49 ` Pierrick Bouvier
2025-04-18 17:29 ` [RFC PATCH v3 12/14] hw/arm/virt: Register valid CPU types dynamically Philippe Mathieu-Daudé
2025-04-18 17:29 ` [RFC PATCH v3 13/14] qemu/target_info: Add target_aarch64() helper Philippe Mathieu-Daudé
2025-04-19 1:09 ` Pierrick Bouvier
2025-04-19 12:54 ` Philippe Mathieu-Daudé
2025-04-19 15:52 ` Pierrick Bouvier
2025-04-22 6:04 ` Markus Armbruster [this message]
2025-04-22 17:50 ` Pierrick Bouvier
2025-04-22 18:24 ` Markus Armbruster
2025-04-22 18:49 ` Pierrick Bouvier
2025-04-18 17:29 ` [RFC PATCH v3 14/14] hw/arm/virt: Replace TARGET_AARCH64 -> target_aarch64() Philippe Mathieu-Daudé
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=87tt6g91fq.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=anjo@rev.ng \
--cc=berrange@redhat.com \
--cc=philmd@linaro.org \
--cc=pierrick.bouvier@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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.