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. 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. Then we can have an automatic naming convention "arch-type" which hits this bucket, or "type" which must exist uniquely among all buckets. 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
