On 5/8/2026 11:55 AM, Richard Henderson wrote: > On 5/5/26 17:48, 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 <[email protected]> >> --- >> 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) > > Reviewed-by: Richard Henderson <[email protected]> > > As a followup QOM improvement, we could use this constructor to > explicitly initialize type_table, and drop type_table_get() and its > continual checking for NULL. >
This sounds like a reasonable idea. There should not be any other QOM type registered with a static constructor (previous patch is the only occurrence I found after review), so we should be safe regarding non deterministic call sequence for static ctor. I'll add this in v5. > > r~ Regards, Pierrick
