| Message ID | 20201116224143.1284278-1-ehabkost@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | qom: Use qlit to represent property defaults | expand |
Eduardo Habkost <ehabkost@redhat.com> writes: > Based-on: 20201104160021.2342108-1-ehabkost@redhat.com > Git branch: https://gitlab.com/ehabkost/qemu/-/commits/work/qdev-qlit-defaults > > This extend qlit.h to support all QNum types (signed int, > unsigned int, and double), and use QLitObject to represent field > property defaults. > > It allows us to get rid of most type-specific .set_default_value > functions for QOM property types. What's left? I'm asking because if you create a new way to get rid of most of an old way, you're still left with two ways, which may or may not be an improvement. Moving defaults from code to data sounds attractive to me. Data is easier to reason about than code. For QAPI, we've been talking about defining defaults in the schema for a long time, but nobody has gotten around to finish an implementation.
On Thu, Nov 19, 2020 at 01:39:50PM +0100, Markus Armbruster wrote: > Eduardo Habkost <ehabkost@redhat.com> writes: > > > Based-on: 20201104160021.2342108-1-ehabkost@redhat.com > > Git branch: https://gitlab.com/ehabkost/qemu/-/commits/work/qdev-qlit-defaults > > > > This extend qlit.h to support all QNum types (signed int, > > unsigned int, and double), and use QLitObject to represent field > > property defaults. > > > > It allows us to get rid of most type-specific .set_default_value > > functions for QOM property types. > > What's left? Enums. Enums properties are a mess to implement, and I plan to tackle them later. On all other cases, the external representation of the property value is similar to the internal representation. In the case of enums, the external representation is a string, but the internal representation is an integer. > > I'm asking because if you create a new way to get rid of most of an old > way, you're still left with two ways, which may or may not be an > improvement. I don't think this is an accurate description. We had five different ways of doing this[1]. I replaced four of them with the new qlit-based mechanism, and now we have two. [1] The five different ways were: qdev_propinfo_set_default_value_enum, qdev_propinfo_set_default_value_int, qdev_propinfo_set_default_value_uint, set_default_uuid_auto, and set_default_value_bool. > > Moving defaults from code to data sounds attractive to me. Data is > easier to reason about than code. For QAPI, we've been talking about > defining defaults in the schema for a long time, but nobody has gotten > around to finish an implementation.
On 19/11/20 18:13, Eduardo Habkost wrote: >> What's left? > Enums. Enums properties are a mess to implement, and I plan to > tackle them later. > > On all other cases, the external representation of the property > value is similar to the internal representation. In the case of > enums, the external representation is a string, but the internal > representation is an integer. > I would have expected a string QLit to work with enums, is there a reason why it doesn't? Paolo
On Thu, Nov 19, 2020 at 06:23:30PM +0100, Paolo Bonzini wrote: > On 19/11/20 18:13, Eduardo Habkost wrote: > > > What's left? > > Enums. Enums properties are a mess to implement, and I plan to > > tackle them later. > > > > On all other cases, the external representation of the property > > value is similar to the internal representation. In the case of > > enums, the external representation is a string, but the internal > > representation is an integer. > > > > I would have expected a string QLit to work with enums, is there a reason > why it doesn't? It would work, but it would be more inconvenient for callers. Right now they use the C enum constant instead of a string.
On 19/11/20 18:55, Eduardo Habkost wrote: > On Thu, Nov 19, 2020 at 06:23:30PM +0100, Paolo Bonzini wrote: >> On 19/11/20 18:13, Eduardo Habkost wrote: >>>> What's left? >>> Enums. Enums properties are a mess to implement, and I plan to >>> tackle them later. >>> >>> On all other cases, the external representation of the property >>> value is similar to the internal representation. In the case of >>> enums, the external representation is a string, but the internal >>> representation is an integer. >>> >> >> I would have expected a string QLit to work with enums, is there a reason >> why it doesn't? > > It would work, but it would be more inconvenient for callers. > Right now they use the C enum constant instead of a string. It matches what you have to do already for compat props, so it's not a big deal. I would say just use strings. Paolo
On Thu, Nov 19, 2020 at 07:25:15PM +0100, Paolo Bonzini wrote: > On 19/11/20 18:55, Eduardo Habkost wrote: > > On Thu, Nov 19, 2020 at 06:23:30PM +0100, Paolo Bonzini wrote: > > > On 19/11/20 18:13, Eduardo Habkost wrote: > > > > > What's left? > > > > Enums. Enums properties are a mess to implement, and I plan to > > > > tackle them later. > > > > > > > > On all other cases, the external representation of the property > > > > value is similar to the internal representation. In the case of > > > > enums, the external representation is a string, but the internal > > > > representation is an integer. > > > > > > > > > > I would have expected a string QLit to work with enums, is there a reason > > > why it doesn't? > > > > It would work, but it would be more inconvenient for callers. > > Right now they use the C enum constant instead of a string. > > It matches what you have to do already for compat props, so it's not a big > deal. I would say just use strings. No problem to me. I'll do.