Markus Armbruster <arm...@redhat.com> writes:
> Alex Bennée <alex.ben...@linaro.org> writes: > >> When specialising general purpose objects it is sometimes useful to >> "fix" some of the properties that were configurable by the base >> classes. We will use this facility when specialising >> vhost-user-device. >> >> Signed-off-by: Alex Bennée <alex.ben...@linaro.org> >> --- >> qapi/qom.json | 2 ++ >> include/qom/object.h | 16 +++++++++++++++- >> qom/object.c | 14 ++++++++++++++ >> qom/object_interfaces.c | 9 ++++++--- >> qom/qom-qmp-cmds.c | 1 + >> softmmu/qdev-monitor.c | 1 + >> 6 files changed, 39 insertions(+), 4 deletions(-) >> >> diff --git a/qapi/qom.json b/qapi/qom.json >> index a877b879b9..4cda191f00 100644 >> --- a/qapi/qom.json >> +++ b/qapi/qom.json >> @@ -33,12 +33,14 @@ >> # @description: if specified, the description of the property. >> # >> # @default-value: the default value, if any (since 5.0) >> +# @fixed: if specified if value has been fixed (since 8.1) > > Wat? > >> # >> # Since: 1.2 >> ## >> { 'struct': 'ObjectPropertyInfo', >> 'data': { 'name': 'str', >> 'type': 'str', >> + 'fixed': 'bool', >> '*description': 'str', >> '*default-value': 'any' } } >> > > qom-list and qom-list-properties return a list of this. Use cases for > the new member? The use-case is this whole series. Basically I want to have a generic device (vhost-user-device) which has a bunch of control knobs the user can fiddle with (e.g. virtio id, num_vqs and the like). However for the specialised versions of this device (e.g. vhost-user-gpio) some of these values (e.g. virtio id) need to be fixed. Mark suggested maybe just duplicating the properties in a similar way to DEFINE_AUDIO_PROPERTIES but that doesn't really address the problem wanting to "fix" some of the values for the subclasses and preventing the user from changing things. I appreciate this is possibly a horrible hack so I'm open to the QOM experts showing me the correct way to model this sort of behaviour. -- Alex Bennée Virtualisation Tech Lead @ Linaro