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.
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
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
> >
> >
> >
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
