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

On 29/4/25 10:23, Markus Armbruster wrote: > Pierrick Bouvier <pierrick.bouvier(a)linaro.org&gt; writes: > > > On 4/28/25 4:07 AM, Markus Armbruster wrote: > > > Peter Krempa <pkrempa(a)redhat.com&gt; 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.... 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.