On Tue, Nov 10, 2020 at 12:12:31PM +0100, Paolo Bonzini wrote: > On 10/11/20 10:53, Stefan Hajnoczi wrote: > > "allowed_values" > > The list all values that the device implementation accepts for this > > migration > > parameter. Integer ranges can be described using "<min>-<max>" strings. > > > > Examples: ['a', 'b', 'c'], [1, 5, 7], ['0-255', 512, '1024-2048'], [true] > > > > This member is optional. When absent, any value suitable for the type > > may be > > given but the device implementation may refuse certain values. > > I'd rather make this simpler: > > - remove allowed_values for strings. Effect: discourages using strings as > enums, leaving them only for free-form values such as vendor name or model > name.
And introduce an enum type? > - remove allowed_values for bools. If off_value is absent the only allowed > value is init_value. If off_value is present, both true and false are > allowed (and !off_value is the "on_value", so to speak). Makes sense. > - change allowed_values into allowed_min and allowed_max for int values. > Advantage: avoids having to parse strings as ranges. Disadvantage: removes > expressiveness (cannot say "x must be a power of two"), but I'm not sure > it's worth the extra complication. Yes, the current syntax supports sparse ranges and multiple ranges. The trade-off is that a tool cannot validate inputs beforehand. You need to instantiate the device to see if it accepts your inputs. This is not great for management tools because they cannot select a destination device if they don't know which exact values are supported. Daniel Berrange raised this requirement in a previous revision, so I wonder what his thoughts are? Stefan
signature.asc
Description: PGP signature
