On Sat, Oct 03, 2026 at 12:43:19AM +0800, Yonggang Luo wrote: > On Sat, Oct 3, 2026 at 12:32 AM Daniel P. Berrangé <[email protected]> > wrote: > > > > "is_available" is probably a bit overkill as a mechanism for > > introspecting, when we just need to return a list of targets, > > Since we have that already we might as well use it initially > > though. > > I have experimented with x86_64/i386 arm/aarch64 riscv32/riscv64 so > that I can tell: > using is_available will be a better option. As we can use inherent the > is_available from > parent, if we just use a bit set like QEMU_ARCH_ARM, then that means we need > specify it for every single machine. And if any customization is > needed, for example, depends > on KVM config or other accel config or any condition not just > QEMU_ARCH_*, then is_available > still needed, so I would insist is_available with a TargetInfo* > parameter, then all concern > will be addressed. > > > > > > > > >> Does it matches what you would expect? > > > >> > > > >> Also, for compatibility with existing binaries, should we accept -M > > > >> $arch-virt also? I feel like it does not hurt and would make thing > > > >> simpler to switch between existing and new binary. > > > > > > > > Same reason -M $arch-virt, indeed like -M $arch:virt, but $arch-virt > > > > would be even harder. > > > > Because "-" is a valid separator in machine names, ":" is not a valid > > > > machine name. > > > > So without init QOM, we can not reliably identify "$arch-virt" belongs > > > > to which target. > > > > > > > > > > From the conversation above, Daniel and I are not in favor to have any > > > kind of parsing based on this string. So either we'll pick virt, or the > > > real qom name, but not anything else. > > > > Yeah, I'm leaning more towards always exposing the $arch-virt names > > in all binaries, and also exposing 'virt' in the traditional > > binaries only. > > I have a question, do we expose the "$arch-virt" as a machine "name" > and expose "$arch-virt" as machine qom "typename"; > or expose "virt" as a machine "name" and expose "$arch-virt" as > machine qom "typename".
The human facing machine "name" is the important one. For the QOM typename, I don't really mind either way. If we can keep the QOM typename and human "name" matching that's nice, but if they differ, then it is not a big deal - your series has the patch to expose the QOM typename in QAPI 'MachineInfo' which addresses the only downside of them differing. So whatever approach works best when implementing the ideas... 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 :|
