On Mon, Aug 24, 2026 at 2:54 PM Pierrick Bouvier < [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]> > >> --- > >> 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]/ I do not see why this is needed yet. My patches is based on https://patchew.org/QEMU/[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
