On 5/18/2026 9:17 AM, Markus Armbruster wrote:
Daniel Henrique Barboza <[email protected]> writes:
Ccing Drew Jones
On 5/17/2026 4:28 PM, khaled saleh wrote:
The priv_spec property accepts a fixed set of values (v1.10.0, v1.11.0,
v1.12.0, v1.13.0) but was implemented as a string type with manual
string-to-enum conversion in custom getter/setter functions.
Convert it to use QEnumLookup with visit_type_enum() for:
- Automatic input validation by the visitor framework
- QMP introspection support (valid values are discoverable)
- Reduced boilerplate (priv_spec_from_str/to_str removed)
This resolves the "FIXME enum?" comment in cpu.c.
Signed-off-by: khaled saleh <[email protected]>
---
This would be an improvement from what we have but I'm not sure if 'enum'
is what we want either. We tend to go towards on/off flags that are more
QMP friendly. So instead of enum property called 'priv_spec' we would have
booleans like "priv_ver_1_11 = on/off" and etc.
And I believe we can't just get rid of the existing string properties all of
a sudden too. The string option would need to go through a deprecation
cycle first, and I'm not even sure if we can re-use the same property name
with 'enum' instead of string (my guess is we can't). So it seems to me that
the 'priv_ver' property is basically doomed to be a string type until it goes
away.
Enums are strings on the wire. Changing a QMP command argument or QOM
property that accepts only a finite set of values from string to enum
with the same set of values is compatible.
In the case of QMP, introspection with query-qmp-schema gets more
precise, which could conveivably confuse management applications.
Non-issue here, I believe.
Thanks for the QMP/QOM infos!
If QMP doesn't care that much, and in a closer look seems like users won't
be impacted (since it'll be the same strings used as input), I believe my
initial reservations are uncalled for and it is ok to go ahead with this
change.
Thanks,
Daniel
