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?
r~
