On 10/8/2026 11:33 AM, Yonggang Luo wrote: > On Fri, Oct 9, 2026 at 2:27 AM Pierrick Bouvier > <[email protected]> wrote: >> >> On 10/8/2026 10:04 AM, Yonggang Luo wrote: >>> On Fri, Oct 9, 2026 at 12:01 AM Pierrick Bouvier >>> <[email protected]> wrote: >>>> >>>> On 10/8/2026 2:56 AM, Yonggang Luo wrote: >>>>>>> How about letting machines (and machines only first), have a new field >>>>>>> 'targets', being a uint32_t mask with an array of EMU_TARGET? >>>>>>> machine->targets = EMU_TARGET_X | EMU_TARGET_Y; >>>>> >>>>> To be explicit state what, I give you a pseudo code to compute >>>>> machine->targets from TypeInfo::is_available(TargetInfo*) >>>>> let targets=0 >>>>> foreach ti of TargetInfo list: >>>>> if (machine::TypeImpl::is_avaible(ti)) >>>>> targets |= 1 << ti->target_arch >>>>> fi >>>>> endif >>>>> So they basically have equivalent effect, and is_available will handle >>>>> other code-needed condition properly such as >>>>> CPU/AccelClass. not restrict to targets, we can also attach the >>>>> KConfig into TargetInfo, so is_available(TargetInfo*) >>>>> also works for Kconfig. that's why I insist this way, it's solved all >>>>> the issues around. >>>>> >>>>> so machine->targets = EMU_TARGET_X | EMU_TARGET_Y; is a good idea, >>>>> and it can be implemented with TypeInfo::is_available(TargetInfo*) >>>>> without much burden. and targets can be saved into a (machine or >>>>> TypeImpl) for fast access when needed, we can compute it >>>>> when the program starts. >>>>> >>>> >>>> In what we described, there is no need to keep any kind of callback, >>>> targets field is sufficient to filter any type declaratively. >>>> >>>> For the KConfig related types, I would really be keen to leave that >>>> available for now, and add a proper error message later. >>> >>> Thanks, much clearer now, I was working for full KConfig related types >>> support >>> because I am trying to keep qemu-system-$arch to be a symlink to qemu-system >>> which will still work without breaking anything. If we do not keep this then >>> I machine::targets or TypeInfo::targets would be the best solution, I think >>> TypeInfo::targets is better, and copy it into TypeImpl::targets. and give a >>> API >>> to retrieve it, for example: >>> uint64_t *object_class_get_targets(ObjectClass *klass); >>> >> >> We can exclude the goal to replace existing binaries with a symlink for now. >> >> Please do not add this to TypeInfo, but to MachineClass instead, as >> explained in previous email. > > I didn't see any simple way to do this, and don't know how, I am sorry. > MachineClass init procedure is scattered, how would that be? I am > afraid I am not > able to get this done. If you can give some prepare work would be appreciated >
You can take a look at "git grep mc->desc". That's where you want to set targets. Also see MachineClass::desc, to see where to declare the field. There might be some machine classes that lack a class_init function, and thus will require to introduce it. If you find any occurrence that is not easy to solve, let me know, I'll help on it. >> If you want to reduce upcoming frustration, I would really recommend you >> stick to this, and to a single machine to start. So we can validate the >> series, review it, and then you can iterate. >> > Add "targets" struct members as TypeInfo::targets and >> TypeImpl::targets, and >>> copy from TypeInfo into TypeImpl for later access with >>> object_class_get_targets >>> Then we can use it for filtering machines and cpus without burden. >>> >>> How to dealt with >>> https://lore.kernel.org/qemu-devel/[email protected]/ >>> >>> It's using is_available. >>> >> >> .targets field can be conditioned by ifdef for config vs user, since >> what we have everything needed in build system allows to duplicate >> objects between user and system. >> >> #ifdef CONFIG_USER_ONLY >> .targets = ... >> #else >> .targets = ... >> #endif >> >> If that's not enough, it means the type has to be duplicated in some >> ways to resolve ambiguity (especially for 32 vs 64 bits variants). >> >>> Maybe all using the way like >>> Subject: [PATCH v2 07/18] target/riscv: Runtime register MAX and BARE CPUs >>> https://lore.kernel.org/qemu-devel/[email protected]/ >> >> I would invite you to focus on a *single* machine first. See how to >> declare it, and how to query which target it supports. Then we can see >> what works/doesn't work, and (in a future series) we can do the same >> thing for cpus. >> >> You'll see that this iterative approach works much better than sending >> huge series. You have my word I'll be reactive and present to help >> continue this effort. >> >> Regards, >> Pierrick > > >
