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