From: Markus Armbruster <armbru@redhat.com>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: "Pierrick Bouvier" <pierrick.bouvier@linaro.org>,
qemu-devel@nongnu.org,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Brian Cain" <brian.cain@oss.qualcomm.com>
Subject: Re: [PATCH] target-info: set target_arch statically
Date: Thu, 05 Feb 2026 10:52:57 +0100 [thread overview]
Message-ID: <877bsr34au.fsf@pond.sub.org> (raw)
In-Reply-To: <e1495603-4ac2-44bb-8b0d-74c45e5f2e66@linaro.org> (Richard Henderson's message of "Thu, 5 Feb 2026 08:22:11 +1000")
Richard Henderson <richard.henderson@linaro.org> writes:
> On 2/5/26 02:36, Pierrick Bouvier wrote:
>> On 2/3/26 5:36 PM, Richard Henderson wrote:
>>> On 2/4/26 05:41, Pierrick Bouvier wrote:
>>>> target_arch() function will reparse target_name() every time if it was
>>>> not set to a proper SYS_EMU_TARGET_* value (when using
>>>> target-info-stub.c), which is not efficient.
>>>>
>>>> Since we want to preserve the constness of TargetInfo but C doesn't give
>>>> us flexible compile time expressions, we simply set target_arch using a
>>>> static constructor once instead.
>>>
>>> A static constructor isn't static initialization.
>>> That said, we can do better with some extra help from meson; see attached.
>>>
>>> I'm mildly annoyed with openrisc vs or1k. We really ought to fix that, but I haven't
>>> looked into what API breakage we get from selecting one or the other.
>>>
>> This was my first approach, and I noticed the or1k issue + missing hexagon in SYS_EMU_TARGET enum. Having a hack for target name in meson.build is *really* ugly IMHO.
>
> I agree.
>
> I assume the qapi string is the one that should take precedence; everything else appears to be merely qemu source level strings. Marcus, can you confirm?
What exactly would you like me to confirm?
I *guess* it's about the messy part of the patch you posted upthread.
There, you have to normalize TARGET_ARCH value 'openrisc' to 'or1k'.
>> At the moment, hexagon is only linux-user, so I thought it didn't make sense to add it to SYS_EMU_TARGET, and I didn't want to go down the rabbit hole to rename or extend this qapi definition, as the initial goal is just to define a field before main, which I consider to be static initialization, even though you might prefer to call it differently.
I figure this is about adding 'hexagon' to SysEmuTarget even though it's
not actually a system emulator target now.
The fact that adding it there helps indicates SysEmuTarget has leaked
into user emulators, and its name has become misleading. Is this true?
> I was only going to ask you to change "statically" to "at startup" there.
>
> On the other hand, system-mode patches for hexagon have been on the list for a while, so I don't think it's jumping the gun too much to include it in SYS_EMU_TARGET at this time.
>
>> I'll let you upstream whatever changes you prefer, and I drop this patch.
>
> Ok, will do.
>
>
> r~
next prev parent reply other threads:[~2026-02-05 9:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 19:41 [PATCH] target-info: set target_arch statically Pierrick Bouvier
2026-02-04 1:36 ` Richard Henderson
2026-02-04 16:36 ` Pierrick Bouvier
2026-02-04 22:22 ` Richard Henderson
2026-02-05 9:52 ` Markus Armbruster [this message]
2026-02-05 22:36 ` Richard Henderson
2026-02-06 6:58 ` Renaming targets (was: [PATCH] target-info: set target_arch statically) Markus Armbruster
2026-02-06 7:21 ` Renaming targets Pierrick Bouvier
2026-02-06 7:38 ` Markus Armbruster
2026-02-06 7:52 ` Pierrick Bouvier
2026-02-04 9:10 ` [PATCH] target-info: set target_arch statically Daniel P. Berrangé
2026-02-04 16:38 ` Pierrick Bouvier
2026-02-04 17:06 ` Anton Johansson via qemu development
2026-02-05 9:29 ` Markus Armbruster
2026-02-05 19:02 ` Pierrick Bouvier
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=877bsr34au.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=brian.cain@oss.qualcomm.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.