Re: [RFC PATCH 04/18] qemu: Introduce 'qemu/legacy_binary_info.h'

[Markus Armbruster <armbru@redhat.com>]

Philippe Mathieu-Daudé <philmd@linaro.org> writes:

> Cc'ing Markus.
>
> On 6/3/25 02:56, Richard Henderson wrote:
>> On 3/5/25 07:39, Philippe Mathieu-Daudé wrote:
>>> +void legacy_binary_info_init(const char *argv0)
>>> +{
>
>
>>> +    for (size_t i = 0; i < ARRAY_SIZE(legacy_binary_infos); i++) {
>>> +        if (!strcmp(legacy_binary_infos[i].binary_name, binary_name)) {
>>> +            current_index = i;
>>> +            return;
>>> +        }
>>> +    }
>
>
>> When testing for errors before and after a patch, I often rename
>> the binary, e.g. qemu-system-aarch64-good / qemu-system-aarch64-bad.
>
> I'd not qemu-system-microblazeel-good to match qemu-system-microblaze.
>
>> Leaving it in the same build directory is required in order to let
>> it find the uninstalled rom images.
>> Is there a way we can preserve something akin to this?
>> Do we need to add the -target command-line option that Pierrick mooted?

Having behavior depend on the binary name is problematic.  When users
run it with some other name (renamed binary, link to binary), behavior
changes, which is generally not desired and may be quite confusing.

I guess you want to do it here to replace multiple binaries by a single
one with several names.  Correct?

The stupid solution is to configure the single binary's behavior the
non-clever way with command line options such as -target, then provide
compatibility wrappers that run the single binary with suitable options.
Drawback: wrappers are slow, ugly, and can also be confusing.  Say when
you rename just the wrapper to -good and -bad.

If we want to go with behavior depending on the binary name, we could
try to reduce confusion by making unorthodox names fail cleanly.  Say
make -target optional only when the binary name matches exactly.

> Not that easy, CLI is evaluated *after* QOM types are registered.
> IIUC we'd need to add this as a -preconfig option, Markus is that right?

Ah, the startup mess.  I don't remember a thing.  Except for the need to
have QMP up and running before any non-trivial startup.  To get that,
the command line needs to be processed this early, too.

-preconfig is a disgusting hack to delay parts of startup until it's
explicitly triggered in the monitor.  Not a general solution for "need
to configurate more before startup", and not sure it helps here.