On 12/2/25 12:43, Philippe Mathieu-Daudé wrote:
On 12/2/25 12:37, Thomas Huth wrote:
On 12/02/2025 12.24, Philippe Mathieu-Daudé wrote:
Introduce the EndianMode type and the DEFINE_PROP_ENDIAN() macros.
Endianness can be BIG, LITTLE or unspecified (default).
Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
---
qapi/common.json | 16 ++++++++++++++++
include/hw/qdev-properties-system.h | 7 +++++++
hw/core/qdev-properties-system.c | 11 +++++++++++
3 files changed, 34 insertions(+)
diff --git a/qapi/common.json b/qapi/common.json
index 6ffc7a37890..217feaaf683 100644
--- a/qapi/common.json
+++ b/qapi/common.json
@@ -212,3 +212,19 @@
##
{ 'struct': 'HumanReadableText',
'data': { 'human-readable-text': 'str' } }
+
+##
+# @EndianMode:
+#
+# An enumeration of three options: little, big, and unspecified
+#
+# @little: Little endianness
+#
+# @big: Big endianness
+#
+# @unspecified: Endianness not specified
+#
+# Since: 10.0
+##
+{ 'enum': 'EndianMode',
+ 'data': [ 'little', 'big', 'unspecified' ] }
Should 'unspecified' come first? ... so that it gets the value 0, i.e.
when someone forgets to properly initialize a related variable, the
chances are higher that it ends up as "unspecified" than as "little" ?
BTW I'm not sure QAPI guaranty enums are following an order
(at least, as in C, I wouldn't rely on that assumption).
