Re: [PATCH 01/27] include/qemu/target-info-qom.h: declare TYPE_TARGET_SPECIFIC interface

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