On Thu, Mar 30, 2017 at 04:23:34PM +0200, Alexander Graf wrote: > On 03/30/2017 04:22 PM, Eduardo Habkost wrote: > > 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. :) > > > As long as we still manage to hit 2.9 with this I'm all happy :).
We won't, as this is not a bug fix and we are past hard freeze. :( -- Eduardo
