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 > 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 -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
