On 10/7/2026 1:50 PM, Yonggang Luo wrote: > On Thu, Oct 8, 2026 at 4:29 AM Pierrick Bouvier > <[email protected]> wrote: >> >> On 10/7/2026 4:48 AM, Yonggang Luo wrote: >>> Register target definitions through constructors instead of >>> MODULE_INIT_TARGET_INFO, making target_info_list() and target_info() >>> available on entry to main(), without explicit initialization or a >>> call to module_call_init(MODULE_INIT_QOM). >>> >>> Keep the target list sorted by target_arch and default to its first >>> entry. Provide an unknown TargetInfo fallback for target-independent >>> tools such as qemu-img and unit tests that link no target-info-def.c >>> objects. >>> >>> Remove the obsolete QOM target-info registration infrastructure and >>> update the multi-target test to inspect target information before >>> initializing QOM. >>> >>> Signed-off-by: Yonggang Luo <[email protected]> >>> --- >>> include/qemu/module.h | 1 - >>> include/qemu/target-info-def.h | 56 +++++++++++++++++++++++++++--- >>> include/qemu/target-info-init.h | 53 ---------------------------- >>> include/qemu/target-info-qom.h | 31 ----------------- >>> include/qemu/target-info.h | 9 +++++ >>> meson.build | 6 ++-- >>> system/vl.c | 4 --- >>> target-info-def.c | 1 - >>> target-info-qom.c | 60 -------------------------------- >>> target-info.c | 61 ++++++++++++++++++++++++++++++++- >>> tests/qtest/fuzz/fuzz.c | 3 -- >>> tests/unit/test-multi-target.c | 12 +++---- >>> 12 files changed, 129 insertions(+), 168 deletions(-) >>> delete mode 100644 include/qemu/target-info-init.h >>> delete mode 100644 include/qemu/target-info-qom.h >>> delete mode 100644 target-info-qom.c >>> >> >> This approach (custom list based) was considered before implementing >> things with QOM Types. The rationale I followed was that if everything >> is in QOM, we might better follow that for consistency sake. >> Yes, the compromise if that we need an extra init step, but it was not a >> problem to add it. > I have issue to add the init step for unit-tests, and hard to write the > -target > parse procedure and get it right. Not means this won't work. but for > me, too much > coupled. >
We already have such a test upstream: https://gitlab.com/qemu-project/qemu/-/blob/master/tests/unit/test-multi-target.c#L35 The init sequence is quite straightforward: ``` /* initialize target types, and only them */ module_call_init(MODULE_INIT_TARGET_INFO); /* we can get the list if we want, for -target or any other purpose */ g_autoptr(GSList) targets = object_class_get_list(TYPE_TARGET_INFO, false); /* set the global target info from any element in this list */ TargetInfo* ti = ...; target_info_qom_set_target_info(ti); /* register rest of QOM types */ module_call_init(MODULE_INIT_QOM); ``` It works fine to implement -target (if we would like to do it), since I implemented it myself. That was also my initial motivation by the way. Also, I appreciate that target-info is NULL by default, it crashes loudly when it has not been set, and make it easy to find who depends on it. > If we treat target_info as a QOM, but QOM needs target_info to set > up(is_avaible). That makes > the init sequence too much of a burden. > See sequence above, the solution is to initialize TARGET_INFO first, before the rest of QOM. You end up with the same result than with a statically initialized list. > > is_available is depends on target_arch > And before this patch, target_arch depends on QOM, pulls user/softmmu because > target_info_init. By moving target-info to be a custom list based, we > can decouple > target-info from qom/softmmu/user. and target-info will always > available once "main(argv, argc)" is entered. We also have the > advantage of doing all sorts > of tests against it. > Which kind of tests are you trying to add? For now, the exact list of places where we need to do this initialize target dance are: - system/vl.c: module_call_init(MODULE_INIT_TARGET_INFO); - tests/qtest/fuzz/fuzz.c: module_call_init(MODULE_INIT_TARGET_INFO); - tests/unit/test-multi-target.c: module_call_init(MODULE_INIT_TARGET_INFO); If we want more tests, I'm totally ok to move this init code to target-info.c, and replace call sites if needed. > > Tools such as qemu-img and unit tests may link target-info.c without any > target-info-def.c objects. Their target list remains empty, so use this > fallback. > Why should this tool get access to target list? qemu-img deals with disk images, and is unrelated to targets. > > static TypeImpl *type_register_internal(const TypeInfo *info) > { > TypeImpl *ti; > > if (!type_name_is_valid(info->name)) { > fprintf(stderr, "Registering '%s' with illegal type name\n", > info->name); > abort(); > } > > if (info->is_available && !info->is_available()) { > return NULL; > } > > ti = type_new(info); > > type_table_add(ti); > return ti; > } > >> >> Is there another good value this list approach brings compared to what >> exists? >> >> Regards, >> Pierrick > > >
