Re: [PATCH 10/12] target-info: add -target and program-name selection

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Aug 26, 2026 at 11:13:05AM -0700, Pierrick Bouvier wrote:
> On 8/26/2026 5:46 AM, Daniel P. Berrangé wrote:
> By implementing *strict* identical behavior with existing binaries, we
> indeed didn't add any new feature, but:
> - we reduced total number of compilation units by 30%
> - we cleaned up a lot of headers and did a lot of refactoring
> - we have a systematic approach to add new targets in single-binary
> while being able to reuse all existing tests without any change.
>
> From my point of view, what you see as a detour was precisely what made
> us progress so far in a year.

No, on the contrary, that's all good stuff.

What I'm considering here is the behaviour of the new proposed
qemu-system and what it needs to be able todo.

Some of this work only appears relevant to a scenario where
qemu-system-$target is dropped in favour of a symlink to the
new qemu-system. That forces qemu-system to be 100% compatible
with the existing binaries, which IMHO is an undesirable
constraint and creates extra work.

We can have the benefits of the compliation unit reduction,
cleaner headers, etc, while still having qemu-system be a
distinct break with the past in a number of areas.

> > If we ignore historical compat and treat qemu-system as a
> > clean break, then I'd suggest that 'target' is not a concept
> > to be exposed to the user at all.
> >
> 
> If your only problem is with having a new -target option, I would be
> happy to just keep the behavior to derive the target from current binary
> name. That's a very small compromise on my side, and -target is just
> here for convenience. It's not the end of the path.

It isn't about the syntax - whether it is implicit from the binary
name or explicit from -target, that's still producing a design
where the target is the top level concept, and machine is a second
level concept. I don't see how that makes sense given the longer
term intent to have machines with heterogeneous CPU targets.

The machine looks like it should be the top level concept, with
target(s) derived from that.

> > The user cares about the machine (and CPUs) they want to run,
> > and their choice in this respect is what should determine the
> > target(s) QEMU needs to enable. We should take
> > 
> >   qemu-system --machine vexpress-a15
> > 
> > that tells us we need the arm target. If we need to distinguish
> > arm7 vs aarch64, then the choice of -cpu should determine 32
> > bs 64 bit.
> > 
> > This extends better into the future world where we have
> > machine type that could involve CPUs from multiple targets.
> > 
> > IOW machine config option / QOM class is what we should pivot
> > off rather than a global target config option.
> > 
> > This likely implies that the MachineClass should gain a class
> > method to query the QEMU_ARCH_XXXX bitmask required. Initially
> > restricted to only a single target, so you can wire that through
> > to the current global target info at startup. Later expanded to
> > support multiple concurrent targets.
> >
> 
> While it sounds nice on paper, you will be doomed to ambiguity with this:
> 
> qemu-system -machine virt -cpu max
> 
> What is your next plan? add an environment variable to solve it?

The machine names need to be globally unique across all targets.
So the 'virt' naming clash needs a rename, such as is done in
an earlier patch in this series.

> Deriving target from argv(0) or -target is explicit, predictable, boring
> and reliable, and it's exactly what we need now.

With the requirement that machine names are globally unique, we can
determine the target(s) directly.

Relying on argv(0) does not appear to work in a heterogeneous future
as target is no longer unique per process, but the machine type would
be unique.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|