On Wed, Oct 28, 2026 at 11:56 AM Pierrick Bouvier
<[email protected]> wrote:
>
> On 10/27/2026 7:15 PM, Yonggang Luo wrote:
> > On Wed, Oct 28, 2026 at 1:40 AM Pierrick Bouvier
> > <[email protected]> wrote:
> >>
> >> On 10/26/2026 9:57 PM, Yonggang Luo wrote:
> >>>> I hope that through the recent series sent on multi target topic, you
> >>>> can see better how to try to slice work in smaller pieces. I try to
> >>>> focus on having a clear goal for each series, and each patch has a
> >>>> unique purpose. Then wait for reviews, and iterate from here.
> >>>
> >>> I have learned much, I need more information or discussion about thow to
> >>> avoid calling target_info() in class_init. You suggest me to use
> >>> is_available
> >>> but I still did not get it, because for multi-target binary, the
> >>> is_available
> >>> will not be called. so adding more things into is_available is
> >>> useless(for my target).
> >>> So I want a more clean explanation of how to do that. (I have already
> >>> tried rename/duplicate
> >>> the QOM name with is_available, too much changes and cumbersome)
> >>>
> >>
> >> First step is to create distinct duplicated types for every QOM type
> >> concerned (like two cpu max, one for arm, one for aarch64), and select
> >> the right one with is_available.
> >
> > I think this is easily implemented. So this is fine.
> >
> >>
> >> Once we have all types correctly duplicated, and using is_available
> >> everywhere, we can replace the callback approach with a declarative
> >> approach (.targets), and register types in distinct buckets.
> >
> > Indeed, we can compute .targets from is_available, as we can create a
> > constant mapping
> > for those target_* is_available callbacks. So the prototype can leverage
> > that.
> >
> >
> >
> >> Then we can have an automatic naming convention "arch-type" which hits
> >> this bucket, or "type" which must exist uniquely among all buckets.
> >
> >
> > So you mean use "<target-name>-<TypeInfo::name>" as the QOM name when
> > registering?
>
> No, it would still be registered without the target prefix. Then, we
> would automatically make an alias as target-type for each separate bucket.
any pseudocode about the bucket? For example, The "virt-machine" qom name will
correspond to multiple totally different TypeInfo, how is this achieved?
Currently the type is directly insert with
static void type_table_add(TypeImpl *ti)
{
assert(!enumerating_types);
g_hash_table_insert(type_table, (void *)ti->name, ti);
}
where should be the bucket, I need to prototype it out so we have a
clear picture and
avoid risks. Or we turn TypeImpl to be a List instead? so we can
iterate on it? when
it supports targets?
>
> > For example, most types are QEMU_ARCH_ALL, then they will be
> > registered multiple times?
> > Or for all type with QEMU_ARCH_ALL, will only be registered a single time,
> > with
> > narrow QEMU_ARCH_*, emulate <target-name>， then register all
> > "<target-name>-<TypeInfo::name>"
> > at type_register_internal?
> >
>
> For this, we can probably keep the type in the global table. I doubt
> there are many machines/cpus concerned.
> And all devices will be available for all targets, as discussed previously.
>
> >
> >>
> >> Yes it's a big change, and it can be done in parallel to current effort
> >> to support multiple targets linked together, it's unrelated.
> >>
> >> Please note that the bucket idea is just an idea at this point, and I'm
> >> not sure if this will be accepted. In all cases, the refactoring for
> >> using is_available and have duplicated first is needed first, so lets
> >> focus on that.
> >>
> >> Regards,
> >> Pierrick
> >
> >
> >
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
