On Tue, Mar 28, 2017 at 02:35:57PM +0200, Alexander Graf wrote:
On 03/28/2017 02:31 PM, Eduardo Habkost wrote:
On Tue, Mar 28, 2017 at 01:26:04PM +0200, Alexander Graf wrote:
[...]
Putting it into a special enum sounds much more fragile than the current
solution to me. We need to bool fallback either way, so I fail to see any
benefit from having the enum.
I don't see why the enum would be more fragile. With the QAPI
enum, we:
* Have a meaningful value for the QOM property 'type' field,
and have some hope to make type information for QOM properties
really useful one day;
* Have the possible values for the property well-documented in
the QAPI schema;
* Have the string<->enum translation code automatically generated
for us;
* Can easily add other values later (I have been planning to
support "feat=host" so "-cpu host/max" aren't special cases in
the code.
Ok, can you create the boilerplate for an OnOff enum type for me and I'll
plug =force into that? All that visitor stuff scares me :).
I can do it, if you don't mind waiting for a few days. :)