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.
