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. Is there another good value this list approach brings compared to what exists? Regards, Pierrick
