On 8/24/2026 1:39 AM, Yonggang Luo wrote: > > > On Mon, Aug 24, 2026 at 2:54 PM Pierrick Bouvier > <[email protected] > <mailto:[email protected]>> wrote: >> >> On 8/22/2026 7:23 AM, Richard Henderson wrote: >> > On 8/21/26 16:51, Pierrick Bouvier wrote: >> >> With the single-binary, we start mixing types for different targets, >> >> that may or may not be available for current one. >> >> >> >> Previously, we implemented an approach based on interfaces, but it >> >> proved to be too limited. It requires duplication between >> >> machines/cpus/devices, and does not handle specific cases where a type >> >> should be available based on a target configuration (Kconfig). >> >> >> >> To solve this, we add a new field, available_if, to TypeInfo. >> >> It is an array containing a list of requirements for type to be >> >> available. >> >> >> >> For now, we have only targets as requirements, but later we'll add >> >> specific target config entries also. >> >> >> >> We also add a TARGET_REQS macro, to declare a list of requirements. For >> >> sanity sake, we don't use a complex variadic macro prefixing each >> >> parameter. It requires a lot of macro boilerplate in C, and prevent >> >> readers to jump easily to definition for each parameter. >> >> >> >> Signed-off-by: Pierrick Bouvier<[email protected] > <mailto:[email protected]>> >> >> --- >> >> include/qemu/target-info.h | 11 +++++++++++ >> >> include/qom/object.h | 5 +++++ >> >> qom/object.c | 10 ++++++++++ >> >> rust/qom/src/qom.rs | 1 + >> >> stubs/meson.build | 1 + >> >> stubs/target-info.c | 11 +++++++++++ >> >> target-info.c | 13 +++++++++++++ >> >> 7 files changed, 52 insertions(+) >> >> create mode 100644 stubs/target-info.c >> >> >> >> diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h >> >> index 6c5b714288e..6379e65bbcf 100644 >> >> --- a/include/qemu/target-info.h >> >> +++ b/include/qemu/target-info.h >> >> @@ -50,6 +50,17 @@ const char *target_cpu_type(void); >> >> */ >> >> bool target_big_endian(void); >> >> +typedef enum TargetReq { >> >> + /* 0 is reserved for end of array */ >> >> + TARGET_REQ_BASE_ARM = 1, >> >> + TARGET_REQ_AARCH64, >> >> + TARGET_REQ_ARM, >> >> +} TargetReq; >> >> + >> > >> > Is there a reason you're inventing Yet Another Enum, especially when >> > target_base_arm etc are based on SysEmuTarget, which itself is used to >> > create bitmasks of targets? >> > >> >> Mostly because we'll have to add CONFIG as TARGET_REQ. (CONFIG_NITRO for >> instance, please see v1), in additions to targets. >> My original implementation was using an interface with a callback, and I >> offered to have this callback as part of TypeInfo. Daniel insisted on >> having a list of constraints for (future) introspection purpose. I think >> it's solving a problem we don't have yet, but need to move on on this >> series, and happy to implement anything that satisfy the community. >> >> In all cases, I'm open to other ideas if you have something to suggest, >> which can represent both target and config knobs, with a simple and >> concise solution. Enum was the best compromise for me, price being >> duplication with existing SysEmuTarget. >> >> > >> > r~ >> > >> >> > > I've implement single binary for arm/riscv at https://patchew.org/ > QEMU/[email protected]/ <https://patchew.org/ > QEMU/[email protected]/> >
Thanks for giving it a try. > I do not see why this is needed yet. > Try running -cpu help, or -device help after applying your series, you'll notice it accidentally exposes all cpus/devices for all targets, so it breaks the fundamental promise to keep existing command line exactly as it is for current binaries. That's why we're trying to solve this filtering issue for all QOM types (machines, cpus and devices) *before* sending the series adding build system for qemu-system + -target option (which I have, waiting on my personal repo). The v2 is a result of a discussion with Daniel on v1, you can read it for details. > My patches is based on https://patchew.org/ > QEMU/[email protected]/ > <https://patchew.org/QEMU/20260724000948.234657-1- > [email protected]/> > ``` > + > +static TargetCpuOps target_cpu_ops; > + > +void target_info_register_cpu_op(const char *cpu_type, size_t offset, > + void *impl) > +{ > + const TargetInfo *ti = target_info(); > + void **slot; > + > + g_assert(ti); > + g_assert(offset + sizeof(void *) <= sizeof(TargetCpuOps)); > + g_assert((offset % sizeof(void *)) == 0); > + > + if (strcmp(cpu_type, ti->cpu_type)) { > + return; > + } > + > + slot = (void **)((char *)&target_cpu_ops + offset); > + if (*slot) { > + error_report("TargetCpuOps already registered for type > '%s' (offset %zu)", > + cpu_type, offset); > + return; > + } > + *slot = impl; > +} > + > +const TargetCpuOps *target_info_cpu_ops(void) > +{ > + return &target_cpu_ops; > +} > ```` > > To see different func for different arch > > -- > 此致 > 礼 > 罗勇刚 > Yours > sincerely, > Yonggang Luo Regards, Pierrick
