Pierrick Bouvier <pierrick.bouv...@linaro.org> writes:
> On 4/28/25 4:07 AM, Markus Armbruster wrote:
>> Peter Krempa <pkre...@redhat.com> writes:
>>
>>> So what should libvirt do once multiple targets are supported?
>>>
>>> How do we query CPUs for each of the supported targets?
>>>
>
> It's kind of a similar question we have to solve now with QEMU code.
> What happens when a symbol is duplicated, and available only for several
> targets?
>
> In this case, we found various approaches to solve this:
> - unify this symbol for all targets (single implementation)
> - unify all targets to provide this symbol (multiple impl, all targets)
> - rename symbols adding {arch} suffix, so it's disambiguated by name
> - create a proper interface which an available function (multiple impl,
> selective targets)
>
> In the case of query-cpu-definitions, my intuition is that we want to
> have a single implementation, and that we return *all* the cpus, merging
> all architectures. In the end, we (and libvirt also) should think out of
> the "target" box. It's an implementation detail, based on the fact QEMU
> had 'targets' associated to various binaries for a long time and not a
> concept that should leak into all consumers.
>
>>> Will the result be the same if we query them one at a time or all at
>>> once?
>>
>> Pierrick's stated goal is to have no noticable differences between the
>> single binary and the qemu-system-<target> it covers. This is obviously
>> impossible if we can interact with the single binary before the target
>> is fixed.
>>
>
> Right.
> At this point, we can guarantee the target will be fixed before anything
> else, at the start of main(). It's obviously an implementation choice,
> but to be honest, I don't see what we would gain from having a "null"
> default QEMU target, unable to emulate anything.
>
>>>> This requires fixing the target before introspection. Unless this is
>>>> somehow completely transparent (wrapper scripts, or awful hacks based on
>>>> the binary's filename, perhaps), management applications may have to be
>>>> adjusted to actually do that.
>>>
>>> As noted filename will not work. Users can specify any filename and
>>> create override scripts or rename the binary.
>>
>> True.
>>
>
> I would prefer to not open this pandora box on this thread, but don't
> worry, the best will be done to support all those cases, including
> renaming the binary, allowing any prefix, suffix, as long as name stays
> unambiguous. If you rename it to qemu-ok, how can you expect anything?
>
> We can provide the possibility to have a "default" target set at compile
> time, for distributors creating their own specific QEMU binaries. But in
> the context of classical software distribution, it doesn't make any sense.
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.
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.
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.
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!
Distributions have packaged renamed binaries. qemu-kvm has been used
quite widely.
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?
