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