On 8/26/2026 4:07 PM, 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.
>
> 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.
>
> Can we please just have a plain callback?
>
Something like:
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -494,6 +494,7 @@ struct TypeInfo
void (*class_init)(ObjectClass *klass, const void *data);
void (*class_base_init)(ObjectClass *klass, const void *data);
const void *class_data;
+ bool (*is_available)(void);
const InterfaceInfo *interfaces;
And used as:
...
is_available = target_aarch64.
...
We would keep the exact same set of types registered than today.
Would that work for you Richard?
>
> r~
>
Regards,
Pierrick
