qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 08/12] qom: allow for properties to become "fixed"


From: Alex Bennée
Subject: Re: [PATCH 08/12] qom: allow for properties to become "fixed"
Date: Mon, 17 Apr 2023 12:26:31 +0100
User-agent: mu4e 1.11.2; emacs 29.0.90

Markus Armbruster <armbru@redhat.com> writes:

> Alex Bennée <alex.bennee@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.bennee@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]