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.
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
