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.
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.
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.
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.
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
