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