Re: [PATCH v2 3/7] qom/object: register OBJECT and INTERFACE QOM types before main

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Apr 30, 2026 at 09:03:52AM -0700, Pierrick Bouvier wrote:
> On 4/30/2026 12:12 AM, Daniel P. Berrangé wrote:
> > On Wed, Apr 29, 2026 at 08:56:22PM -0700, Pierrick Bouvier wrote:
> >> Those types are special, as they are the base of all other QOM types. In
> >> next commit, we'll introduce an extra step in module initialization for
> >> target-info-* types.
> >>
> >> However, those types depend on TYPE_OBJECT, which is only registered
> >> at MODULE_INIT_QOM step.
> >>
> >> To avoid having to introduce another step, and modify all code calling
> >> module_call_init(MODULE_INIT_QOM), we simply register those base types
> >> directly in the static constructor, before anything else.
> >>
> >> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> >> ---
> >>  qom/object.c | 4 +---
> >>  1 file changed, 1 insertion(+), 3 deletions(-)
> >>
> >> diff --git a/qom/object.c b/qom/object.c
> >> index f981e270440..a5d268d0722 100644
> >> --- a/qom/object.c
> >> +++ b/qom/object.c
> >> @@ -2839,7 +2839,7 @@ static void object_class_init(ObjectClass *klass, const void *data)
> >>                                    NULL);
> >>  }
> >>  
> >> -static void register_types(void)
> >> +static void __attribute__((constructor)) register_types(void)
> >>  {
> >>      static const TypeInfo interface_info = {
> >>          .name = TYPE_INTERFACE,
> >> @@ -2857,5 +2857,3 @@ static void register_types(void)
> >>      type_interface = type_register_internal(&interface_info);
> >>      type_register_internal(&object_info);
> >>  }
> >> -
> >> -type_init(register_types)
> > 
> > IMHO this should have been done using the MODULE_INIT_QOM_EARLY
> > approach that I suggested on v1, rather than special casing both
> > the base classes and MODULE_INIT_TARGET_INFO
> >
> 
> I'm ok to follow your approach if you really prefer it.
> However, can you specify what should be the semantic to put in comment
> for it? I have trouble finding to explain what is early vs non early,
> while it's clear for me what is TARGET_INFO vs REST_OF_QOM.

I don't think we need to set our strong rules. It is just an early
startup hook to be used by classes which are a dependency of other
initialization code.  Conceptually this is similar to what we did
in system/vl.c, where we have various stages for creating -object
args. What goes in each stage is simply determined by a functional
need at the point in time.

> As well, adding a INIT_QOM_EARLY implies we need to call it in all
> locations where we already call INIT_QOM for future-proofing, which
> seems very redundant. Should we had it or not?

Yep, that's true, but not the end of the world imho.

Ultimately an solution is a bit of a hack. Long term what we need
to do is follow glib's approach from GType and have "just in time"
initialization on first use which will make everything "just work"
without having to think about ordering. I didn't want to suggest
that now though, as it has potential to be a can of worms.