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. 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. Regards, Pierrick
