Richard Henderson <[email protected]> writes:
> On 2/5/26 19:52, Markus Armbruster wrote:
>>> 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'.
>
> Yes. I wanted you to confirm that changing the string in qapi is a
> non-starter, therefore
> 'or1k' is the string we should standardize on.
Yes, changing enum value @or1k is problematic.
Enum SysEmuTarget is visible in QMP: query-target return member @arch,
query-cpus-fast return member @target. These are stable interfaces.
I can see two ways to change the enum value to @openrisc:
1. We create a new qemu-system-openrisc, identical to qemu-system-or1k
except for the target name. We deprecate qemu-system-or1k and
SysEmuTarget member @or1k, and remove them after the grace period.
I doubt it's worth the bother.
2. We cheat: we rename with the excuse that the target is bottom support
tier, and our compatibility promise doesn't apply there.
I don't think that's a good idea. If we want to qualify our
compatibility promise with tiers, we better define the tiers and what
they mean for the promise *first*. Related:
From: Daniel P. Berrangé <[email protected]>
Subject: [PATCH] docs/about: propose OS platform/arch support tiers
Date: Thu, 15 Jan 2026 18:01:23 +0000
Message-ID: <[email protected]>
https://lore.kernel.org/qemu-devel/[email protected]/
>> 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?
>
> Yes. The target_info structure is used for both user and system, and one of
> these fields
> is the SysEmuTarget entry.
Then SysEmuTarget has become misleading.
We *can* fix that: QAPI type names are not part of the external
interface by design.
