On Wed, Aug 05, 2026 at 12:10:27PM -0700, Pierrick Bouvier wrote: > On 8/5/2026 9:53 AM, Daniel P. Berrangé wrote: > > On Wed, Aug 05, 2026 at 09:16:20AM -0700, Pierrick Bouvier wrote: > >> On 8/5/2026 7:05 AM, Daniel P. Berrangé wrote: > >>> On Fri, Jul 24, 2026 at 12:09:21AM +0000, Pierrick Bouvier wrote: > >>>> In the next commits, We'll replace the logic to filter QOM types per > >>>> target from a static one (based on INTERFACES) to a runtime one, based > >>>> on is_available() function, that can be overriden per class. > >>>> > >>>> Introduce the new interface we'll use for that. > >>>> > >>>> Signed-off-by: Pierrick Bouvier <[email protected]> > >>>> --- > >>>> include/qemu/target-info-qom.h | 15 +++++++++++++++ > >>>> target-info-qom.c | 5 +++++ > >>>> 2 files changed, 20 insertions(+) > >>>> > >>>> diff --git a/include/qemu/target-info-qom.h > >>>> b/include/qemu/target-info-qom.h > >>>> index 91be415ed33..83eb537333b 100644 > >>>> --- a/include/qemu/target-info-qom.h > >>>> +++ b/include/qemu/target-info-qom.h > >>>> @@ -14,6 +14,21 @@ > >>>> > >>>> #define TYPE_TARGET_INFO "target-info" > >>>> > >>>> +#define TYPE_TARGET_SPECIFIC "target-specific" > >>>> + > >>>> +typedef struct TargetSpecific TargetSpecific; > >>>> + > >>>> +typedef struct TargetSpecificClass { > >>>> + InterfaceClass parent_class; > >>>> + > >>>> + bool (*is_available)(void); > >>>> +} TargetSpecificClass; > >>>> + > >>>> +#define TARGET_SPECIFIC(obj) \ > >>>> + INTERFACE_CHECK(TargetSpecific, (obj), TYPE_TARGET_SPECIFIC) > >>>> +DECLARE_CLASS_CHECKERS(TargetSpecificClass, TARGET_SPECIFIC, > >>>> + TYPE_TARGET_SPECIFIC) > >>> > >>> Looking through the series,I don't really see the point > >>> in this interface. Why is this not possible to do by > >>> adding 'is_available' to MachineClass. It would make > >>> the rest of the series simpler and especially avoid the > >>> need to introduced yet more series of macros for defining > >>> machine classes. > >>> > >> > >> We'll need the exact same interface for cpus, and devices also. IMHO, it > >> makes sense to have this in an external interface, instead of forcing it > >> to be present in all cpus/devices/machines. I also considered adding it > >> directly in Object class directly (would be the simplest), but I felt it > >> would be hard to motivate it. > > > > I don't see a need for the common interface across cpus/devices/etc as > > as code that's filtering only cares about the specific types. It also > > definitely doesn't beloong in Object class, but the Object class could > > be changed to make it simpler. > > > > We agree on this. > > > The object_class_get_list() method could get a 'bool filter(ObjectClass > > *cl)' > > callback which could be invoked on each class to filter it. > > > > That said I find it pretty undesirable as an approach that we're > > registering classes that can't then be used in a given situation. > > This has a ripple effect where every bit of code that iterates over > > classes needs changing to add filtering after the fact. It is also > > not great for scalability, as it means every QEMU process will have > > the union of all classes for all targets registered, most of which > > have to be discarded / ignored at runtime. > > > > This is inherent to the nature of having a single binary. > We need to cover those two requirements: > 1. having a filter mechanism (per target) > 2. have all the classes accessible for the heterogeneous machines that > will be coming in the future > > 1. could be covered by what you describe, however, it breaks 2. For > this, you need to be able to register all types by design.
Even the heterogeneous machines aren't going to need all the classes from all 30+ targets that QEMU supports. IIUC, the current approach relies on '--target <blah>' to select which target we need. Would the heterogeneous machines not just change that to allow "--target <this> --target <that>". It still looks like we should be able to significantly limit what we register for heterogeneous machines. 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 :|
