On Thu, Oct 29, 2026 at 2:27 AM Pierrick Bouvier
<[email protected]> wrote:
>
> On 10/27/2026 8:06 PM, Yonggang Luo wrote:
> > 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?
> >
>
> I would suggest you first introduce duplicated types + is_available
> where is needed before trying to do this change.
Hi Pierrick:
Done locally. I'll post this first.
>
> For this, as suggested previously, remove the global target_info, and
> make sure all types can be initialized without crashing, proving
> class_init don't depend on target_info.
And stuck here. I am trying to do class_init with target_info==NULL.
with your idea about provide a buckets for each QOM typename, and changed
many objects.c still have not got a workable solution yet.
>
> Regards,
> Pierrick
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
