On Wed, Aug 26, 2026 at 04:07:22PM -0700, Richard Henderson wrote:
> On 8/21/26 16:53, Pierrick Bouvier wrote:
> > > > > > > > > Based on this, I'm much more in favor or 1. The fact
> > > > > > > > > availability
> > > > > > > > > information is in the same location than type definition is
> > > > > > > > > the biggest
> > > > > > > > > advantage for me.
> > > > > > > > >
> > > > > > > > > On example given above, this would give something like this:
> > > > > > > > > static const TypeInfo emulated_card_info = {
> > > > > > > > > .name = TYPE_EMULATED_CCID,
> > > > > > > > > .parent = TYPE_CCID_CARD,
> > > > > > > > > .instance_size = sizeof(EmulatedState),
> > > > > > > > > .class_init = emulated_class_initfn,
> > > > > > > > > .is_available = target_config_X,
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > Would that work for you?
> > > > > > > > > Do you have a 3rd way to offer to solve the problem we have?
> > > > > > > > In the case of user creatable objects, we represented a classes'
> > > > > > > > conditional availablity in QAPI schema. For example:
> > > > > > > >
> > > > > > > > { 'struct': 'InputLinuxProperties',
> > > > > > > > 'data': { 'evdev': 'str',
> > > > > > > > '*grab_all': 'bool',
> > > > > > > > '*repeat': 'bool',
> > > > > > > > '*grab-toggle': 'GrabToggleKeys' },
> > > > > > > > 'if': 'CONFIG_LINUX' }
> > > > > > > >
> > > > > > > > Now this isn't quite a match for what we want, as QAPI schema is
> > > > > > > > common to all targets and used to control the code generator to
> > > > > > > > turn off output. Thus the permitted CONFIG_xxx are only those in
> > > > > > > > config-host.mak, not any from $TARGET-softmmu-config-devices.mak
> > > > > > > >
> > > > > > > > The other scenario in QAPI is the concept of features:
> > > > > > > >
> > > > > > > > { 'struct': 'SevCommonProperties',
> > > > > > > > 'data': { '*sev-device': 'str',
> > > > > > > > '*cbitpos': 'uint32',
> > > > > > > > 'reduced-phys-bits': 'uint32',
> > > > > > > > '*kernel-hashes': 'bool' },
> > > > > > > > 'features': ['confidential-guest-reset']}
> > > > > > > >
> > > > > > > > where again we just have a list of named strings. Features are
> > > > > > > > fully
> > > > > > > > dynamic, and crucially they are introspectable so applications
> > > > > > > > can
> > > > > > > > query at runtime what is available.
> > > > > > > >
> > > > > > > > The introspection concept is something that is highly likely to
> > > > > > > > be
> > > > > > > > relevant to our use cases here. If we have a single binary with
> > > > > > > > all
> > > > > > > > types, it would be very valuable to be able to query it once to
> > > > > > > > discover everything in one go, instead of havnig to query it
> > > > > > > > over
> > > > > > > > and over again for each target. That implies the application
> > > > > > > > doing
> > > > > > > > the query needs to be told about per-target usage restrictions
> > > > > > > > on
> > > > > > > > types it is querying.
>
> Having read through Pierrick's v2, I'm not a fan of inventing a new
> enumeration, creating a switch, calling exactly the functions we could have
> registered directly.
>
> I think the misunderstanding here, Dan, is that the filter is for the
> non-heterogeneous '-target foo' case. In the target-foo case, the
> introspection is not highly likely, because we don't have it now. The only
> point is to have, at the end of registration, exactly the same set of
> classes as we have now.
That's not what this code gives us though. At the end of registration
we have the union of all classes from all targets - qom-list-type lists
everything. Instead when querying classes, the consumers have to apply
filtering which IMHO is too late.
My suggestion was to take an approach that filters at the time of
registration, so we never register classes that are irrelevant for
the target and thus don't need filtering by consumers.
Having looked at Yonggang's add-on series though that actually
introduces 'qemu-system', I think we should not do filtering at
all, neither at registration or by consumers.
The filtering is only needed if we want 'qemu-system -target aarch64'
to be a perfect match for 'qemu-system-aarch64'. I think that is a
mistaken goal, and is creating uneccessary work.
Instead declare that 'qemu-system' always reports everything that
was built into it and avoid having to create this filtering logic
entirely.
> The introspection case is perhaps probable in the heterogeneous case, where
> the filtering will not apply. In the heterogeneous case we just register
> *everything* and let the magic runtime defined machine pick and choose.
> Thus incorporating the filter into the introspection is pointless. That
> said, I *suspect* there will be very little in the way of introspection at
> all -- I suspect that users will simply create their machine description,
> attempt to instantiate, and error out if there are missing classes.
Introspection remains important, but I do now agree that filtering is
pointless - both for introspection and more generally.
"qemu-system --machine help"
should list *everything* for all targets that are built in to it
without filtering too.
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 :|
