Re: [PATCH 0/5] qom: prepare a TypeBucket for same-name target variants

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

On Fri, Nov 06, 2026 at 03:03:41AM +0800, Yonggang Luo wrote:
> This series prepares QOM to hold more than one TypeImpl under the same name, one
> per target, so a multi-target binary can register same-name types without
> renaming them. Nothing uses it yet.
> 
> type_table maps each name to a TypeBucket, which holds the variants and the
> union of their QEMU_ARCH_* masks. Registration still aborts when masks overlap,
> and a name lookup returns the one variant left for the selected target.
> type_register_targets() registers a variant for a target mask.
> type_register_static() is unchanged, so binaries keep one TypeImpl per name.
> 
> The change stays in qom and target-info and does not conflict with the virt QOM
> name or is_available series.
> 
> Daniel asked what a TypeBucket means. This is that prototype, based on the
> bucket idea from Pierrick.

Thank you for sending this.

IIUC the overall idea here is not all that different from the
existing 'is_available' callback approach. It is still allowing
us to have multiple different classes registered with the same
name. Instead of a opaque callback being used for the filter,
each type is tagged with an explicit target, which can be
filtered on.

So the end result is still the same, we have multiple QOM classes
with the same name, and dynamically filter which are visible to
the management app at runtime. It is slightly better in the that
filtering is data driven, instead of callback driven, but IMHO
this still doesn't address the fundamental historical design
flaw of having clashing QOM type names.

IMHO we need to work from a principal that we should produce a
This gives us a unified type model across the whole of QEMU which
is *invariant at runtime*.  This means type names must be unique
and statically defined at build time, and that properties must
be unique and unconditionally defined against classes at build
time.

The property part in particular is not tied to the multi-target
work. We have other technical debt cleanup work going on that
moves from registering properties against the object instance,
to registering properties against the object class, to produce
an invariant class definition. Removing target-specific property
registration is a natural part of that we would want to do even
without the multi-target motivation.

I've proposed a refinement of my previous PoC from last week that
properly adapts the machine types to unique names:

  https://lists.gnu.org/archive/html/qemu-devel/2026-11/msg02706.html

and pulled in your patches for removing target specific properties
there, since although not a dependency, it is complementary.

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