docs/about/deprecated.rst | 31 +++++ hw/core/qdev-properties.c | 29 ++-- hw/i386/sgx.c | 2 +- hw/intc/ioapic.c | 3 +- include/hw/core/qdev-properties.h | 38 +++--- include/qom/object.h | 215 +++++++++++++++++++++++++++--- qom/object.c | 177 ++++++++++++++++++++---- qom/object_interfaces.c | 5 + qom/qom-hmp-cmds.c | 2 +- qom/qom-qmp-cmds.c | 7 +- system/vl.c | 6 +- target/i386/cpu.c | 28 ++-- 12 files changed, 448 insertions(+), 95 deletions(-)
Hi,
This is the v2 trying to introduce property flags to detect user's
property setting (from CLI/QMP/HMP). I dropped RFC tag since previous
RFC v1 [1].
Though this work the follow-up of v2.6 & v2.7 machines' removal [2],
now it is decoupled from [2] totally since v2 doesn't detect compat
property and only focuses on external user setting, so this series is
based on master branch at the commit 28a6ca268c2c ("Merge tag 'single-
binary-20260203' of https://github.com/philmd/qemu into staging"). And
you can also find the code here:
https://gitlab.com/zhao.liu/qemu/-/tree/prop-flags-v2.3-02-08-2026
This series introduces 3 property flags:
* USER_SET:
Any external user property setting (from CLI/HMP/QMP) is marked as
USER_SET.
* DEPRECATED:
Once a property is marked as DEPRECATED, any external user property
setting will trigger a warning.
* INTERNAL:
Once a property is marked as INTERNAL, any external user property
setting will cause an error.
More details or document for these 3 flags, you can refer patch 7.
Compared with RFC v1, v2 mainly:
* introduce USER_SET property flag to identify all user's setting.
- patch 7 for document.
* construct DEPRECATED & INTERNAL flag on USER_SET.
- patch 7 for document.
* cover more comprehensive user set cases.
- patch 8-13.
* provide examples about new flags (USER_SET/DEPRECATED/INTELNAL).
- patch 15/16/17 are examples for DEPRECATED flag.
- patch 18 is the example for INTERNAL flag.
- patch 20 is the example for USER_SET flag.
I think v2 should now cover "nearly" all cases (patch 8-13) where users
set properties: one approach is to trace the call chain of
object_property_set().
Even if there are cases that were missed, they can be easily addressed
based on this series:
object_property_set(obj, ...);
/* Insert this call after object_property_set(). */
object_property_set_flags(obj, ..., OBJ_PROP_FLAG_USER_SET, ...);
[1]: RFC v1:
https://lore.kernel.org/qemu-devel/20251202170502.3228625-1-zhao1.liu@intel.com/
[2]: hw/i386/pc: Remove deprecated 2.6 and 2.7 PC machines
https://lore.kernel.org/qemu-devel/20260108033051.777361-1-zhao1.liu@intel.com/
Thanks and Best Regards,
Zhao
---
Zhao Liu (21):
qom/object: use BIT macro for ObjectPropertyFlags
qom/object: cache ObjectPropertyFlags in ObjectProperty
qom/object: factor out object_class_property_try_add()
qom/object: add flags argument in object_{class_}property_try_add()
qom/object: rename object_{class_}property_try_add() to
object_{class_}property_add_full()
qom/object: add helpers to set/get/clear property flags
qom/object: introduce user interaction flags for properties
qom/object: add from_user argument in object_property_parse()
qom/object: mark global property set from CLI as USER_SET
qom/qom-hmp-cmd: mark properties set from HMP (non-JSON) "qom-set" as
USER_SET
qom/qom-qmp-cmd: mark properties set from QMP/HMP (JSON) "qom-set" as
USER_SET
qom/object_interfaces: mark properties set from qdict & keyval as
USER_SET
system/vl: mark property set in object_parse_property_opt() as
USER_SET
hw/core/qdev-properties: allow qdev properties accept flags
target/i386: deprecate fill-mtrr-mask property
target/i386: deprecate cpuid-0xb property
hw/intc/ioapic: deprecate version property
target/i386: mark x-consistent-cache property as internal-only
target/i386: remove redundant validation for lbr-fmt property
target/i386: detect user provided lbr-fmt via property flag
hw/core/qdev-properties: support valid default value for
DEFINE_PROP_UINT64_CHECKMASK
docs/about/deprecated.rst | 31 +++++
hw/core/qdev-properties.c | 29 ++--
hw/i386/sgx.c | 2 +-
hw/intc/ioapic.c | 3 +-
include/hw/core/qdev-properties.h | 38 +++---
include/qom/object.h | 215 +++++++++++++++++++++++++++---
qom/object.c | 177 ++++++++++++++++++++----
qom/object_interfaces.c | 5 +
qom/qom-hmp-cmds.c | 2 +-
qom/qom-qmp-cmds.c | 7 +-
system/vl.c | 6 +-
target/i386/cpu.c | 28 ++--
12 files changed, 448 insertions(+), 95 deletions(-)
--
2.34.1
On Tue, Feb 10, 2026 at 11:23:27AM +0800, Zhao Liu wrote: > Hi, > > This is the v2 trying to introduce property flags to detect user's > property setting (from CLI/QMP/HMP). I dropped RFC tag since previous > RFC v1 [1]. This says what the series is proposing, but IMHO what is more important here is explaining why this either desirable or appropriate to add as general facility in QOM. The idea that code should take different action for a given fixed value, based on whether the value was set by the user, or left on the default, makes me very uncomfortable. There have been a number of situations where something that was initially a boolean flag, actually needed to be a tri-state instead, to provide semantics like "On", "Off", "Auto". This "user set" flag could support such behaviour indirectly, but since "user set" is an internal concept we'd still be only exposing a boolean externally, while using a tri-state internally. That does not give the full flexibility of a tri-state, because internally if we wanted to have the default to be "yes", it offers no way for the mgmt app to put it back to "auto". For properties that are not booleans, it is much less obvious to me whether we actually need a distinct "not set" concept at all. So overall, at a conceptual level, I don't think that QOM should care about /how/ a value came to be set. It should have no direct awareness of the "user input", rather it just represents the configuration of the system at a given point in time, however that came to pass. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Hi Daniel,
On Tue, Feb 10, 2026 at 10:12:38AM +0000, Daniel P. Berrangé wrote:
> Date: Tue, 10 Feb 2026 10:12:38 +0000
> From: "Daniel P. Berrangé" <berrange@redhat.com>
> Subject: Re: [PATCH v2 00/21] qom: introduce property flags to track
> external user input
>
> On Tue, Feb 10, 2026 at 11:23:27AM +0800, Zhao Liu wrote:
> > Hi,
> >
> > This is the v2 trying to introduce property flags to detect user's
> > property setting (from CLI/QMP/HMP). I dropped RFC tag since previous
> > RFC v1 [1].
>
> This says what the series is proposing, but IMHO what is more important
> here is explaining why this either desirable or appropriate to add as
> general facility in QOM.
Yes, sorry this cover letter I wrote is overly simplified.
This series tries to control the property access against external user.
USER_SET is the base to track external user's behavior, and DEPRECATED &
INTERNAL flags provide different levels of access control.
Though the DEPRECATED flag does not inherently restrict access, I think
such a warning also serves as a form of control.
The idea of restricting external access to properties is from previous
discussions [*] about internal properties.
[*]: How to mark internal properties:
https://lore.kernel.org/qemu-devel/2f526570-7ab0-479c-967c-b3f95f9f19e3@redhat.com/
Since that disscussion, currently all properties expected to be
"internal" have an “x-” prefix — while this approach can work, it clearly
confuses the original meaning of “x-”, which actually means "unstable".
Therefore, I think the optimal approach is to provide the capability to
restrict external access to the property — that is, to implement the
"true" internal property.
Based on this, it seems impossible to implement an internal property
without tracking user input in the QOM?
> The idea that code should take different action for a given fixed value,
> based on whether the value was set by the user, or left on the default,
> makes me very uncomfortable.
>
> There have been a number of situations where something that was initially
> a boolean flag, actually needed to be a tri-state instead, to provide
> semantics like "On", "Off", "Auto".
>
> This "user set" flag could support such behaviour indirectly, but since
> "user set" is an internal concept we'd still be only exposing a boolean
> externally, while using a tri-state internally. That does not give the
> full flexibility of a tri-state, because internally if we wanted to
> have the default to be "yes", it offers no way for the mgmt app to
> put it back to "auto".
>
> For properties that are not booleans, it is much less obvious to me
> whether we actually need a distinct "not set" concept at all.
USER_SET primarily serves the INTERNAL and DEPRECATED flags. However,
its another function is to indicates whether the external user has
touched the property.
But, Hmm, I think "auto" and USER_SET don't have conflict?
IIUC, "auto" means the user requests that QEMU make the decision itself.
However, just like my patch 19 cleanup of “lbr-fmt”, that property
explicitly requires users to provide a valid value. Even we have "auto"
for uint64, "auto" can't address this case.
Similarly, the x86 CPU's topology IDs (used for hotplug) - "thread-id"/
"core-id"/"module-id"..., also require the user to set valid and accurate
values; they cannot be replaced with "auto".
These existing cases all check user input for magic numbers. I hope to
simplify these existing logic using USER_SET.
> So overall, at a conceptual level, I don't think that QOM should care
> about /how/ a value came to be set. It should have no direct awareness
> of the "user input", rather it just represents the configuration of the
> system at a given point in time, however that came to pass.
I also think the ideal situation is not to distinguish between external
and internal - however, exposing properties to external users makes code
evolution painful...
Thanks,
Zhao
On Tue, Feb 10, 2026 at 11:28:07PM +0800, Zhao Liu wrote:
> Hi Daniel,
>
> On Tue, Feb 10, 2026 at 10:12:38AM +0000, Daniel P. Berrangé wrote:
> > Date: Tue, 10 Feb 2026 10:12:38 +0000
> > From: "Daniel P. Berrangé" <berrange@redhat.com>
> > Subject: Re: [PATCH v2 00/21] qom: introduce property flags to track
> > external user input
> >
> > On Tue, Feb 10, 2026 at 11:23:27AM +0800, Zhao Liu wrote:
> > > Hi,
> > >
> > > This is the v2 trying to introduce property flags to detect user's
> > > property setting (from CLI/QMP/HMP). I dropped RFC tag since previous
> > > RFC v1 [1].
> >
> > This says what the series is proposing, but IMHO what is more important
> > here is explaining why this either desirable or appropriate to add as
> > general facility in QOM.
>
> Yes, sorry this cover letter I wrote is overly simplified.
>
> This series tries to control the property access against external user.
> USER_SET is the base to track external user's behavior, and DEPRECATED &
> INTERNAL flags provide different levels of access control.
>
> Though the DEPRECATED flag does not inherently restrict access, I think
> such a warning also serves as a form of control.
>
> The idea of restricting external access to properties is from previous
> discussions [*] about internal properties.
>
> [*]: How to mark internal properties:
> https://lore.kernel.org/qemu-devel/2f526570-7ab0-479c-967c-b3f95f9f19e3@redhat.com/
>
> Since that disscussion, currently all properties expected to be
> "internal" have an “x-” prefix — while this approach can work, it clearly
> confuses the original meaning of “x-”, which actually means "unstable".
>
> Therefore, I think the optimal approach is to provide the capability to
> restrict external access to the property — that is, to implement the
> "true" internal property.
>
> Based on this, it seems impossible to implement an internal property
> without tracking user input in the QOM?
So the main thing that pushes us into using QOM for internal properties
is the machine type compatibility code. eg where we bulk set stuff using
compat_props_add(m->compat_props, hw_compat_7_0, hw_compat_7_0_len);
compat_props_add(m->compat_props, pc_compat_7_0, pc_compat_7_0_len);
That logic is all QOM based. Using QOM isn't our exclusive approach, as
we have machine types sometimes setting object fields directly. eg
static void pc_i440fx_machine_7_0_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_i440fx_machine_7_1_options(m);
pcmc->enforce_amd_1tb_hole = false;
compat_props_add(m->compat_props, hw_compat_7_0, hw_compat_7_0_len);
compat_props_add(m->compat_props, pc_compat_7_0, pc_compat_7_0_len);
}
but that only works for properties against the machine type, not compat
properties against devices, since we have no direct access to the other
classes/instances.
If we want to be able to control hardware compat, without exposing
something as a user facing tunable, then internal-only QOM props seems
inescapable.
I do still wonder if we genuinely need internal-only QOM props for
machine type compat ?
Whether using a public 'x-' prefixed property or an internal only
property, we're constrained by the need to retain the behaviour
semantics for as long as the machine type exists. I don't see an
internal only property giving us significantly more freedom here.
We can already rename a 'x-' property however we want with no
notice, as long as the machine type doesn't change behaviour.
> > The idea that code should take different action for a given fixed value,
> > based on whether the value was set by the user, or left on the default,
> > makes me very uncomfortable.
> >
> > There have been a number of situations where something that was initially
> > a boolean flag, actually needed to be a tri-state instead, to provide
> > semantics like "On", "Off", "Auto".
> >
> > This "user set" flag could support such behaviour indirectly, but since
> > "user set" is an internal concept we'd still be only exposing a boolean
> > externally, while using a tri-state internally. That does not give the
> > full flexibility of a tri-state, because internally if we wanted to
> > have the default to be "yes", it offers no way for the mgmt app to
> > put it back to "auto".
> >
> > For properties that are not booleans, it is much less obvious to me
> > whether we actually need a distinct "not set" concept at all.
>
> USER_SET primarily serves the INTERNAL and DEPRECATED flags. However,
> its another function is to indicates whether the external user has
> touched the property.
>
> But, Hmm, I think "auto" and USER_SET don't have conflict?
>
> IIUC, "auto" means the user requests that QEMU make the decision itself.
> However, just like my patch 19 cleanup of “lbr-fmt”, that property
> explicitly requires users to provide a valid value. Even we have "auto"
> for uint64, "auto" can't address this case.
I just meant "auto" as one possible "default" behaviour where a traditional
boolean was in use, not for all possible types. The right answer for a
default is contextually dependent.
For a uint64, a default value would involve some sentinal value, or it
could involve a pair of related properties. For example, we have
host-phys-bits=on
phys-bits=NNN
as a pair that work together, so you don't need a magic phys-bits value
to represent "use host value".
> Similarly, the x86 CPU's topology IDs (used for hotplug) - "thread-id"/
> "core-id"/"module-id"..., also require the user to set valid and accurate
> values; they cannot be replaced with "auto".
Again I wasn't suggestnig an "auto" value for every scenario, that was
just an example in a "bool" context. An ID value of "0" is a traditional
default for numeric values, which is fine assuming you don't need to
dinstinguish 0 as a valid value, from 0 as an invalid value needing user
input.
> I also think the ideal situation is not to distinguish between external
> and internal - however, exposing properties to external users makes code
> evolution painful...
I don't think it does. Code evolution is painful as long as the machine
type using the prop needs to exist with fixed semantics, whether it is
internal or public with x- prefix.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, 10 Feb 2026, Zhao Liu wrote: > On Tue, Feb 10, 2026 at 10:12:38AM +0000, Daniel P. Berrangé wrote: >> Date: Tue, 10 Feb 2026 10:12:38 +0000 >> From: "Daniel P. Berrangé" <berrange@redhat.com> >> Subject: Re: [PATCH v2 00/21] qom: introduce property flags to track >> external user input >> >> On Tue, Feb 10, 2026 at 11:23:27AM +0800, Zhao Liu wrote: >>> Hi, >>> >>> This is the v2 trying to introduce property flags to detect user's >>> property setting (from CLI/QMP/HMP). I dropped RFC tag since previous >>> RFC v1 [1]. >> >> This says what the series is proposing, but IMHO what is more important >> here is explaining why this either desirable or appropriate to add as >> general facility in QOM. > > Yes, sorry this cover letter I wrote is overly simplified. > > This series tries to control the property access against external user. > USER_SET is the base to track external user's behavior, and DEPRECATED & > INTERNAL flags provide different levels of access control. > > Though the DEPRECATED flag does not inherently restrict access, I think > such a warning also serves as a form of control. > > The idea of restricting external access to properties is from previous > discussions [*] about internal properties. > > [*]: How to mark internal properties: > https://lore.kernel.org/qemu-devel/2f526570-7ab0-479c-967c-b3f95f9f19e3@redhat.com/ > > Since that disscussion, currently all properties expected to be > "internal" have an “x-” prefix — while this approach can work, it clearly > confuses the original meaning of “x-”, which actually means "unstable". > > Therefore, I think the optimal approach is to provide the capability to > restrict external access to the property — that is, to implement the > "true" internal property. > > Based on this, it seems impossible to implement an internal property > without tracking user input in the QOM? > >> The idea that code should take different action for a given fixed value, >> based on whether the value was set by the user, or left on the default, >> makes me very uncomfortable. >> >> There have been a number of situations where something that was initially >> a boolean flag, actually needed to be a tri-state instead, to provide >> semantics like "On", "Off", "Auto". >> >> This "user set" flag could support such behaviour indirectly, but since >> "user set" is an internal concept we'd still be only exposing a boolean >> externally, while using a tri-state internally. That does not give the >> full flexibility of a tri-state, because internally if we wanted to >> have the default to be "yes", it offers no way for the mgmt app to >> put it back to "auto". >> >> For properties that are not booleans, it is much less obvious to me >> whether we actually need a distinct "not set" concept at all. > > USER_SET primarily serves the INTERNAL and DEPRECATED flags. However, > its another function is to indicates whether the external user has > touched the property. > > But, Hmm, I think "auto" and USER_SET don't have conflict? > > IIUC, "auto" means the user requests that QEMU make the decision itself. > However, just like my patch 19 cleanup of “lbr-fmt”, that property > explicitly requires users to provide a valid value. Even we have "auto" > for uint64, "auto" can't address this case. > > Similarly, the x86 CPU's topology IDs (used for hotplug) - "thread-id"/ > "core-id"/"module-id"..., also require the user to set valid and accurate > values; they cannot be replaced with "auto". > > These existing cases all check user input for magic numbers. I hope to > simplify these existing logic using USER_SET. > >> So overall, at a conceptual level, I don't think that QOM should care >> about /how/ a value came to be set. It should have no direct awareness >> of the "user input", rather it just represents the configuration of the >> system at a given point in time, however that came to pass. > > I also think the ideal situation is not to distinguish between external > and internal - however, exposing properties to external users makes code > evolution painful... So another way could be to not use properties for internal settings but add another set of internal properties for those. These could be set the same way but stored in a different hash table and not get mixed with introspectable and user changable properties. But maybe that would be too much refactoring. Regards, BALATON Zoltan
On Tue, Feb 10, 2026 at 10:12:38AM +0000, Daniel P. Berrangé wrote: > On Tue, Feb 10, 2026 at 11:23:27AM +0800, Zhao Liu wrote: > > Hi, > > > > This is the v2 trying to introduce property flags to detect user's > > property setting (from CLI/QMP/HMP). I dropped RFC tag since previous > > RFC v1 [1]. > > This says what the series is proposing, but IMHO what is more important > here is explaining why this either desirable or appropriate to add as > general facility in QOM. > > The idea that code should take different action for a given fixed value, > based on whether the value was set by the user, or left on the default, > makes me very uncomfortable. > > There have been a number of situations where something that was initially > a boolean flag, actually needed to be a tri-state instead, to provide > semantics like "On", "Off", "Auto". But "auto" is exactly a property specific way to work around this. With this, we could allow "auto" for any property (except strings I guess) without per property code. > This "user set" flag could support such behaviour indirectly, but since > "user set" is an internal concept we'd still be only exposing a boolean > externally, while using a tri-state internally. That does not give the > full flexibility of a tri-state, because internally if we wanted to > have the default to be "yes", it offers no way for the mgmt app to > put it back to "auto". I do not get it. Of course user set is an external concept. It is user controllable! > For properties that are not booleans, it is much less obvious to me > whether we actually need a distinct "not set" concept at all. > > > So overall, at a conceptual level, I don't think that QOM should care > about /how/ a value came to be set. It should have no direct awareness > of the "user input", rather it just represents the configuration of the > system at a given point in time, however that came to pass. > > > With regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Feb 10, 2026 at 05:44:50AM -0500, Michael S. Tsirkin wrote: > On Tue, Feb 10, 2026 at 10:12:38AM +0000, Daniel P. Berrangé wrote: > > On Tue, Feb 10, 2026 at 11:23:27AM +0800, Zhao Liu wrote: > > > Hi, > > > > > > This is the v2 trying to introduce property flags to detect user's > > > property setting (from CLI/QMP/HMP). I dropped RFC tag since previous > > > RFC v1 [1]. > > > > This says what the series is proposing, but IMHO what is more important > > here is explaining why this either desirable or appropriate to add as > > general facility in QOM. > > > > The idea that code should take different action for a given fixed value, > > based on whether the value was set by the user, or left on the default, > > makes me very uncomfortable. > > > > There have been a number of situations where something that was initially > > a boolean flag, actually needed to be a tri-state instead, to provide > > semantics like "On", "Off", "Auto". > > But "auto" is exactly a property specific way to work around this. > With this, we could allow "auto" for any property (except strings I > guess) without per property code. > > > > This "user set" flag could support such behaviour indirectly, but since > > "user set" is an internal concept we'd still be only exposing a boolean > > externally, while using a tri-state internally. That does not give the > > full flexibility of a tri-state, because internally if we wanted to > > have the default to be "yes", it offers no way for the mgmt app to > > put it back to "auto". > > I do not get it. Of course user set is an external concept. > It is user controllable! If a property is modelled as a tri-state today the user can explicitly request any of the three values -object foo,prop=on -object foo,prop=off -object foo,prop=auto If a property is modelled as a boolean, and we have this new internal "user set" flag to represent the "auto" scenario, the user can only do -object foo,prop=on -object foo,prop=off we're missing the ability to explicitly request the "auto" value, which could be needed if we decide the internal default should be either "on" or "off". This "user default" flag concept is special casing support for tri-states in a way that is worse than what we can already do in QAPI. That feels like a mistake / bad path to go down to me. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, 10 Feb 2026, Daniel P. Berrangé wrote: > On Tue, Feb 10, 2026 at 05:44:50AM -0500, Michael S. Tsirkin wrote: >> On Tue, Feb 10, 2026 at 10:12:38AM +0000, Daniel P. Berrangé wrote: >>> On Tue, Feb 10, 2026 at 11:23:27AM +0800, Zhao Liu wrote: >>>> Hi, >>>> >>>> This is the v2 trying to introduce property flags to detect user's >>>> property setting (from CLI/QMP/HMP). I dropped RFC tag since previous >>>> RFC v1 [1]. >>> >>> This says what the series is proposing, but IMHO what is more important >>> here is explaining why this either desirable or appropriate to add as >>> general facility in QOM. >>> >>> The idea that code should take different action for a given fixed value, >>> based on whether the value was set by the user, or left on the default, >>> makes me very uncomfortable. >>> >>> There have been a number of situations where something that was initially >>> a boolean flag, actually needed to be a tri-state instead, to provide >>> semantics like "On", "Off", "Auto". >> >> But "auto" is exactly a property specific way to work around this. >> With this, we could allow "auto" for any property (except strings I >> guess) without per property code. >> >> >>> This "user set" flag could support such behaviour indirectly, but since >>> "user set" is an internal concept we'd still be only exposing a boolean >>> externally, while using a tri-state internally. That does not give the >>> full flexibility of a tri-state, because internally if we wanted to >>> have the default to be "yes", it offers no way for the mgmt app to >>> put it back to "auto". >> >> I do not get it. Of course user set is an external concept. >> It is user controllable! > > If a property is modelled as a tri-state today the user can explicitly > request any of the three values > > -object foo,prop=on > -object foo,prop=off > -object foo,prop=auto > > If a property is modelled as a boolean, and we have this new internal > "user set" flag to represent the "auto" scenario, the user can only > do > > -object foo,prop=on > -object foo,prop=off > > we're missing the ability to explicitly request the "auto" value, > which could be needed if we decide the internal default should be > either "on" or "off". In this case the auto setting would be not setting the property at all to any value by the user. > This "user default" flag concept is special casing support for > tri-states in a way that is worse than what we can already do in > QAPI. That feels like a mistake / bad path to go down to me. I also don't really like the USER_SET name so commented to rename to EXTERNAL but thinking more do we need both EXTERNAL/USER_SET and INTERNAL? One of the two would be the default behaviour for untagged properties so maybe we only need to flag INTERNAL to omit them from introspection and user setting but don't need to touch normal user settable properties (apart from adding deprecarion_message that also replaces DEPRECATED flag. But I don't have clear idea or opinion on this so these are more questions than suggestions. Regards, BALATON Zoltan
© 2016 - 2026 Red Hat, Inc.