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. :) -- Eduardo
