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

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 29/4/25 10:23, Markus Armbruster wrote:
> Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:
> 
>> On 4/28/25 4:07 AM, Markus Armbruster wrote:
>>> Peter Krempa <pkrempa@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.

Rather than using non-constant argv[0] Pierrick suggested to add a
single CLI option '-target' which selects the corresponding TargetInfo
structure to use at runtime. I.e. for ARM:

https://lore.kernel.org/qemu-devel/20250424222112.36194-12-philmd@linaro.org/

For distros qemu-system-arm could be a shell script prepending
'-target arm' while passing the arguments calling qemu-system.

If a distro wants to name a binary 'qemu-kvm' it can drop the
-target option and hard-wire its target_info() to a distro-specific
TargetInfo implementation, or &target_info_x86_64_system.

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

Ah! Same same.

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