Re: [RFC PATCH 0/3] single-binary: make QAPI generated files common

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

On 4/29/25 2:20 AM, Thomas Huth wrote:
> On 29/04/2025 10.23, Markus Armbruster wrote:
> ...
>> I don't wish to derail this thread, but we've been dancing around the
>> question of how to best fix the target for some time.  I think we should
>> talk about it for real.
>>

Sure, and no problem about that, that's welcome!
I'm not eluding the conversation, but I just feel that as long as we 
can't really build this single-binary and share this, it's impossible 
for people to try it and make a judgment based on rationale facts about it.

Opinions and taste matter, but it's even better when we all have the 
same thing and can try solutions and post facts instead.

>> Mind, this is not an objection to your larger "single binary" idea.  It
>> could be only if it was an intractable problem, but I don't think it is.
>>
>> You want the single binary you're trying to create to be a drop-in
>> replacement for per-target binaries.
>>
>> "Drop-in replacement" means existing usage continues to work.
>> Additional interfaces are not a problem.
>>
>> To achieve "drop-in replacement", the target needs to be fixed
>> automatically, and before the management application can further
>> interact with it.
>>
>> If I understand you correctly, you're proposing to use argv[0] for that,
>> roughly like this: assume it's qemu-system-<target>, extract <target>
>> first thing in main(), done.
>>
>> What if it's not named that way?  If I understand you correctly, you're
>> proposing to fall back to a compiled-in default target.
>>
>> I don't think this is going to fly.
> 
> I tend to disagree. For normal users that consume QEMU via the distros, the
> check via argv[0] should be good enough. For developers, I think we can
> assume that they are adaptive enough to use an additional "-target" option
> in case they mis-named their binary in a bad way.
> 
>> Developers rename the binary all the time, and expect this not to change
>> behavior.  For instance, I routinely rename qemu-FOO to qemu-FOO.old or
>> qemu-FOO.COMMIT-HASH to let me compare behavior easily.
> 
> Developers should already be aware that this can cause trouble, since e.g.
> the qtests are deriving the target architecture from the binary name
> already. See the qtest_get_arch() function.
> 
>> We could relax the assumption to support such renames.  Developers then
>> need to be aware of what renames are supported.  Meh.
>>
>> The more we relax the pattern, the likelier surprising behavior becomes.
>>
>> We could mitigate surprises by eliminating the built-in default target.
> 
> Just print out a proper error message if the target cannot be derived from
> argv[0], pointing the users to use "-target", and we should be fine.
> 
> And if someone renames their "qemu-sytem-aarch64" symlink to
> "qemu-system-x86_64" and still expect to run aarch64 images that way, that's
> just plain stupidity.
> 
>> Users invoke their binaries with their own names, too.  If Joe R. User
>> finds qemu-system-<joe's-fav-target> too much to type, and creates a
>> symlink named q to it, more power to him!
> 
> They can also either use shell aliases or short shell scripts to achieve
> that goal, so that's not really a show stopper.
> 
>> Distributions have packaged renamed binaries.  qemu-kvm has been used
>> quite widely.
> 
> Yes, and QEMU already checks for that naming in configure_accelerators() ...
> so that's rather another indicator that we can go with configuration via
> argv[0] :-)
> 
>> In neither of these cases, relaxing the pattern helps.
>>
>> The least bad solution I can see so far is a new option -target.
>>
>> Instead of turning the target-specific binaries into links to / copies
>> of the single binary, they become wrappers that pass -target as the
>> first option.  We need to make sure this option is honored in time then,
>> which should be easy enough.
>>
>> If you invoke the single binary directly, you need to pass -target
>> yourself.  If you don't to pass it, or pass it late in the command line,
>> you open up a window for interaction with indeterminate target.
>> Target-specific interfaces could exhibit different behavior then, even
>> fail.  That's fine under "additional interfaces are not a problem".
>>
>> Thoughts?
> 
> Shell script wrappers always have the problem that they break the direct
> usage of debuggers like "valgrind" or "gdb" with the target binary, so
> that's also not the best solution.
> 
> I'd go with Pierrick's idea to try to determine the target via argv[0]. And
> for people who really want to rename their binary in a way that makes it
> impossible to determine the target automatically, just provide the "-target"
> option as fallback solution, too.
> 
>    Thomas
> 

I agree 100% with what Thomas said.

Regarding the "Rename the binary and things should work", I was thinking 
of something like:
guess_target(argv) {
   binary=argv[0];
   if (binary.contains("qemu-system-arm")) {
     set_target(&target_info_system_arm);
   } else if (binary.contains("qemu-system-aarch64") {
     set_target(&target_info_system_aarch64);
   }
   unreachable("can't guess target from " + binary);
}

In short, detect "*qemu-system-{arch}*", with arch being one of the 
available architecture we added to the single binary.

In case someone wants to stress this piece of code by doing:
$ mv qemu-system qemu-system-arm-or-qemu-system-aarch64
Well, we can take the first occurence and call it a day.

To disambiguate a target, we can provide the -target command line 
option, and provide a QEMU_TARGET env var.

With those three ways, I hope we can cover 99.999999% of the use cases.

Anyway, we'll need to have a way to identify the target, and all the 
possible solutions will have shortcomings.
The right question is "Which solution covers the widest percentage of 
use cases ?", and my opinion is that argv[0] + -target + QEMU_TARGET env 
is the best compromise for me at this point.
I'm not keen to have a default target set, but it's a personal opinion 
based on fear of "implicit smart choice hurts", so I'll be happy to 
change my mind with a good argument for it.

Regards,
Pierrick