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? r~
