On 9/26/26 1:15 AM, Yonggang Luo wrote:
- Add machine_class_set_name() so boards can keep a stable -M name
when the QOM type is uniquified. machine_class_base_init still
defaults the name to the QOM type without -machine.
- Document that MachineClass::name is the -M name, not the QOM type.
- Sort -M help by MachineClass::name so order matches the printed names
when QOM types are prefixed (arm-virt-11.1-machine vs virt-11.1).
Signed-off-by: Yonggang Luo <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
---
hw/core/machine.c | 6 ++++++
include/hw/core/boards.h | 12 +++++++++++-
system/vl.c | 8 +++-----
3 files changed, 20 insertions(+), 6 deletions(-)
First, I'm not opposed to this series, and if anyone wants to pull this,
I'm ok with that decision. It's just unclear for me what will be
direction after this step.
If I understand correctly, the goal here is to allow to register
multiple "virt" machines, while still having distinct QOM types behind
the hood, which does no affect behavior of current binaries who have
only a single "virt" type at most.
That said, if we project in the future where we have a binary with
multiple of those "virt" machines, how will the current series help? The
situation we'll have is distinct QOM types, that all answer to the name
"virt", so we have no way to select them individually.
Slightly worse, find_machine() will just pick the first machine name
virt, which is a non-deterministic order at the moment.
https://gitlab.com/qemu-project/qemu/-/blob/master/system/vl.c?ref_type=heads#L846
A possible alternative could be to use ".is_available = target_X" on
those virt types, which will ensure only one is effectively registered
at runtime, thus, there is no ambiguity on name or who is the "virt"
machine.
Again, I'm ok if anyone wants to pull this.
Regards,
Pierrick
