On 10/7/2026 4:02 PM, Yonggang Luo wrote: > On Thu, Oct 8, 2026 at 6:31 AM Pierrick Bouvier > <[email protected]> wrote: >> >> 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: > > # Multi targets test > if multi_target_objects != [] > test('test-multi-target', > executable('test-multi-target', > sources: [multi_target_crates, > files('test-multi-target.c')], > dependencies: multi_target_deps, > objects: multi_target_objects, > link_depends: [block_syms, qemu_syms], > link_args: multi_target_link_args), > suite: ['unit']) > endif > > I see this test, I am trying to add tests that do not pull so many > multi_target_objects, as it would be huge.
Agree, we should not add more binary. If you need truly multi targets test, this existing binary is a good place to start: just add a second test in it. > Just pull qom only. And I am trying to call target_info() in > object.c, as inspect machines with > qemu-system is rejected, so maybe that's not an issue anymore > Seems like a good candidate for the multi-target.c test. > > I means Subject: [PATCH v3 00/10] machine: uniquify virt QOM names > https://lore.kernel.org/qemu-devel/[email protected]/#r > > So the current design always rejects types that do not belong to the > current target. Listing them > all is not an option at all. With this restriction, then these are > indeed not needed. > So I'll wait for your work first, otherwise it's always conflicting. > > >> 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 >>> >>> >>> >> > >
