Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev properties accept flags
On Wed, Feb 11, 2026 at 03:30:06PM +0800, Zhao Liu wrote:
On Tue, Feb 10, 2026 at 09:56:08AM +0000, Daniel P. Berrangé wrote:
Date: Tue, 10 Feb 2026 09:56:08 +0000 From: "Daniel P. Berrangé" <berrange@redhat.com> Subject: Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev properties accept flags
On Tue, Feb 10, 2026 at 11:23:41AM +0800, Zhao Liu wrote:
Update qdev property interfaces (qdev_property_add_static() and qdev_class_add_property()) to accept and pass 'ObjectPropertyFlags'. This enables marking qdev properties with flags such as DEPRECATED or INTERNAL.
To facilitate this at the definition level, extend the boolean and uint8_t property macros (as the examples) to accept variable arguments (VA_ARGS). This allows callers to optionally specify flags in the property definition.
Example:
DEFINE_PROP_UINT8("version", IOAPICCommonState, version, IOAPIC_VER_DEF, .flags = OBJECT_PROPERTY_DEPRECATED),
In other places where we track deprecation in QEMU, we have not used a boolean flag. Instead we have used a "const char *deprecation_note" internally, which lets us provide a user facing message, to be printed out in the warn_report, informing them what to do instead (either the feature is entirely removed, or there is a better alternative). IMHO we should be following the same pattern for properties, as it is much more user friendly than just printing a totally generic message "XXXX is deprecated, stop using it"
Yes, rich deprecation hint is better. I think this still depends on USER_SET - distinguish internal/external or not :-(.
Since when we mark a property as deprecated, its code remains in the code tree, and internal calls should not trigger warnings. Deprecation hints are intended to reminder external users.
This depends on where you put the deprecation check. IIUC, all the user facing codepaths for setting properties end up calling through object_set_properties_from_qdict, but internal codepaths don't use that. That method can check & emit the deprecation warnings, without us needing any explicit tracking of "user set" - the use context is derived from the codepath 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 Wed, Feb 11, 2026 at 04:58:47PM +0000, Daniel P. Berrangé wrote:
Date: Wed, 11 Feb 2026 16:58:47 +0000 From: "Daniel P. Berrangé" <berrange@redhat.com> Subject: Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev properties accept flags
On Wed, Feb 11, 2026 at 03:30:06PM +0800, Zhao Liu wrote:
On Tue, Feb 10, 2026 at 09:56:08AM +0000, Daniel P. Berrangé wrote:
Date: Tue, 10 Feb 2026 09:56:08 +0000 From: "Daniel P. Berrangé" <berrange@redhat.com> Subject: Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev properties accept flags
On Tue, Feb 10, 2026 at 11:23:41AM +0800, Zhao Liu wrote:
Update qdev property interfaces (qdev_property_add_static() and qdev_class_add_property()) to accept and pass 'ObjectPropertyFlags'. This enables marking qdev properties with flags such as DEPRECATED or INTERNAL.
To facilitate this at the definition level, extend the boolean and uint8_t property macros (as the examples) to accept variable arguments (VA_ARGS). This allows callers to optionally specify flags in the property definition.
Example:
DEFINE_PROP_UINT8("version", IOAPICCommonState, version, IOAPIC_VER_DEF, .flags = OBJECT_PROPERTY_DEPRECATED),
In other places where we track deprecation in QEMU, we have not used a boolean flag. Instead we have used a "const char *deprecation_note" internally, which lets us provide a user facing message, to be printed out in the warn_report, informing them what to do instead (either the feature is entirely removed, or there is a better alternative). IMHO we should be following the same pattern for properties, as it is much more user friendly than just printing a totally generic message "XXXX is deprecated, stop using it"
Yes, rich deprecation hint is better. I think this still depends on USER_SET - distinguish internal/external or not :-(.
Since when we mark a property as deprecated, its code remains in the code tree, and internal calls should not trigger warnings. Deprecation hints are intended to reminder external users.
This depends on where you put the deprecation check. IIUC, all the user facing codepaths for setting properties end up calling through object_set_properties_from_qdict, but internal codepaths don't use that.
That method can check & emit the deprecation warnings, without us needing any explicit tracking of "user set" - the use context is derived from the codepath
Yeah, most property setting paths are covered by object_set_properties_from_qdict() (I listes these cases in patch 12, including the most common ones: -object/-device and their related HMP/QMP commands). But there're some corner cases which don't go through object_set_properties_from_qdict(), e.g., -global/-accel/"qom-set", etc, those were considerred in patch 9/11/13 (and sorry I should list all cases affected in cover letter :(). These cases are where I find things to be both trivial and tricky, so I manually check them and mark them using USER_SET. Therefore, I think the unified entry point for externally setting properties resides at a lower level—specifically, is object_property_set(), then we need to dientify when object_property_set() is called by external user or not - that's how USER_SET works...(I feel like I'm back where I started). Thanks, Zhao
On Thu, Feb 12, 2026 at 11:25:17PM +0800, Zhao Liu wrote:
On Wed, Feb 11, 2026 at 04:58:47PM +0000, Daniel P. Berrangé wrote:
Date: Wed, 11 Feb 2026 16:58:47 +0000 From: "Daniel P. Berrangé" <berrange@redhat.com> Subject: Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev properties accept flags
On Wed, Feb 11, 2026 at 03:30:06PM +0800, Zhao Liu wrote:
On Tue, Feb 10, 2026 at 09:56:08AM +0000, Daniel P. Berrangé wrote:
Date: Tue, 10 Feb 2026 09:56:08 +0000 From: "Daniel P. Berrangé" <berrange@redhat.com> Subject: Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev properties accept flags
On Tue, Feb 10, 2026 at 11:23:41AM +0800, Zhao Liu wrote:
Update qdev property interfaces (qdev_property_add_static() and qdev_class_add_property()) to accept and pass 'ObjectPropertyFlags'. This enables marking qdev properties with flags such as DEPRECATED or INTERNAL.
To facilitate this at the definition level, extend the boolean and uint8_t property macros (as the examples) to accept variable arguments (VA_ARGS). This allows callers to optionally specify flags in the property definition.
Example:
DEFINE_PROP_UINT8("version", IOAPICCommonState, version, IOAPIC_VER_DEF, .flags = OBJECT_PROPERTY_DEPRECATED),
In other places where we track deprecation in QEMU, we have not used a boolean flag. Instead we have used a "const char *deprecation_note" internally, which lets us provide a user facing message, to be printed out in the warn_report, informing them what to do instead (either the feature is entirely removed, or there is a better alternative). IMHO we should be following the same pattern for properties, as it is much more user friendly than just printing a totally generic message "XXXX is deprecated, stop using it"
Yes, rich deprecation hint is better. I think this still depends on USER_SET - distinguish internal/external or not :-(.
Since when we mark a property as deprecated, its code remains in the code tree, and internal calls should not trigger warnings. Deprecation hints are intended to reminder external users.
This depends on where you put the deprecation check. IIUC, all the user facing codepaths for setting properties end up calling through object_set_properties_from_qdict, but internal codepaths don't use that.
That method can check & emit the deprecation warnings, without us needing any explicit tracking of "user set" - the use context is derived from the codepath
Yeah, most property setting paths are covered by object_set_properties_from_qdict() (I listes these cases in patch 12, including the most common ones: -object/-device and their related HMP/QMP commands).
But there're some corner cases which don't go through object_set_properties_from_qdict(), e.g., -global/-accel/"qom-set", etc, those were considerred in patch 9/11/13 (and sorry I should list all cases affected in cover letter :(). These cases are where I find things to be both trivial and tricky, so I manually check them and mark them using USER_SET.
Therefore, I think the unified entry point for externally setting properties resides at a lower level—specifically, is object_property_set(), then we need to dientify when object_property_set() is called by external user or not - that's how USER_SET works...(I feel like I'm back where I started).
There's a significant different there. Emitting deprecation messages in the API entry points tied to user data is a clear purpose, not open to abuse. Recording the difference between user set & internally set against the object instance persistently is an open ended purpose and based on what we've seen in QEMU in the past, that is highly likely to be mis-used. The idea of supporting deprecations on properties is definitely something we should do, but I really dn't want to see that expressed via the 'user set' mechanism from this series. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
(Sorry for the long silence — just returned from vacation.)
Yeah, most property setting paths are covered by object_set_properties_from_qdict() (I listes these cases in patch 12, including the most common ones: -object/-device and their related HMP/QMP commands).
But there're some corner cases which don't go through object_set_properties_from_qdict(), e.g., -global/-accel/"qom-set", etc, those were considerred in patch 9/11/13 (and sorry I should list all cases affected in cover letter :(). These cases are where I find things to be both trivial and tricky, so I manually check them and mark them using USER_SET.
Therefore, I think the unified entry point for externally setting properties resides at a lower level—specifically, is object_property_set(), then we need to dientify when object_property_set() is called by external user or not - that's how USER_SET works...(I feel like I'm back where I started).
There's a significant different there. Emitting deprecation messages in the API entry points tied to user data is a clear purpose, not open to abuse. Recording the difference between user set & internally set against the object instance persistently is an open ended purpose and based on what we've seen in QEMU in the past, that is highly likely to be mis-used.
The idea of supporting deprecations on properties is definitely something we should do, but I really dn't want to see that expressed via the 'user set' mechanism from this series.
Thank you for your explanation. In practice, as the alternative to USER_SET, I understand we identify the specific API entry points (including object_set_properties_from_qdict and others) and trigger the warning directly within those functions / code path, may I ask if this understanding is right? The current API entry points are somewhat fragmented; perhaps we should consider whether further unification is possible. Regards, Zhao
On Wed, 11 Feb 2026 16:58:47 +0000 Daniel P. Berrangé <berrange@redhat.com> wrote:
On Wed, Feb 11, 2026 at 03:30:06PM +0800, Zhao Liu wrote:
On Tue, Feb 10, 2026 at 09:56:08AM +0000, Daniel P. Berrangé wrote:
Date: Tue, 10 Feb 2026 09:56:08 +0000 From: "Daniel P. Berrangé" <berrange@redhat.com> Subject: Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev properties accept flags
On Tue, Feb 10, 2026 at 11:23:41AM +0800, Zhao Liu wrote:
Update qdev property interfaces (qdev_property_add_static() and qdev_class_add_property()) to accept and pass 'ObjectPropertyFlags'. This enables marking qdev properties with flags such as DEPRECATED or INTERNAL.
To facilitate this at the definition level, extend the boolean and uint8_t property macros (as the examples) to accept variable arguments (VA_ARGS). This allows callers to optionally specify flags in the property definition.
Example:
DEFINE_PROP_UINT8("version", IOAPICCommonState, version, IOAPIC_VER_DEF, .flags = OBJECT_PROPERTY_DEPRECATED),
In other places where we track deprecation in QEMU, we have not used a boolean flag. Instead we have used a "const char *deprecation_note" internally, which lets us provide a user facing message, to be printed out in the warn_report, informing them what to do instead (either the feature is entirely removed, or there is a better alternative). IMHO we should be following the same pattern for properties, as it is much more user friendly than just printing a totally generic message "XXXX is deprecated, stop using it"
Yes, rich deprecation hint is better. I think this still depends on USER_SET - distinguish internal/external or not :-(.
Since when we mark a property as deprecated, its code remains in the code tree, and internal calls should not trigger warnings. Deprecation hints are intended to reminder external users.
This depends on where you put the deprecation check. IIUC, all the user facing codepaths for setting properties end up calling through object_set_properties_from_qdict, but internal codepaths don't use that.
I might be totally wrong, but occasionally I've considered using object_set_properties_from_qdict() internally as much more compact form compared to 'object_new()/set_this_property and set that one too' noodle.
That method can check & emit the deprecation warnings, without us needing any explicit tracking of "user set" - the use context is derived from the codepath
With regards, Daniel
Igor Mammedov <imammedo@redhat.com> writes:
I might be totally wrong, but occasionally I've considered using object_set_properties_from_qdict() internally as much more compact form compared to 'object_new()/set_this_property and set that one too' noodle.
Clear signal our C interface to QOM object configuration is lacking. Going through a QDict is disgusting, though. There has to be a more direct way. One that doesn't involve building temporary trees just so we can use existing visitors. What if we could pass the entire configuration as a struct? Instead of setting properties one by one, pass a struct literal and be done.
On Fri, Mar 06, 2026 at 10:14:23AM +0100, Markus Armbruster wrote:
Igor Mammedov <imammedo@redhat.com> writes:
I might be totally wrong, but occasionally I've considered using object_set_properties_from_qdict() internally as much more compact form compared to 'object_new()/set_this_property and set that one too' noodle.
Clear signal our C interface to QOM object configuration is lacking.
Going through a QDict is disgusting, though. There has to be a more direct way. One that doesn't involve building temporary trees just so we can use existing visitors.
What if we could pass the entire configuration as a struct? Instead of setting properties one by one, pass a struct literal and be done.
Or we pass things as typed variadic args. object_new_args(TYPE_NAME, "foo": someval, "bar: otherval, NULL); we know the QAPI type for each named property, so we know how to interpret type-correct values for each property in the var-args. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
Daniel P. Berrangé <berrange@redhat.com> writes:
On Wed, Feb 11, 2026 at 03:30:06PM +0800, Zhao Liu wrote:
On Tue, Feb 10, 2026 at 09:56:08AM +0000, Daniel P. Berrangé wrote:
Date: Tue, 10 Feb 2026 09:56:08 +0000 From: "Daniel P. Berrangé" <berrange@redhat.com> Subject: Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev properties accept flags
On Tue, Feb 10, 2026 at 11:23:41AM +0800, Zhao Liu wrote:
Update qdev property interfaces (qdev_property_add_static() and qdev_class_add_property()) to accept and pass 'ObjectPropertyFlags'. This enables marking qdev properties with flags such as DEPRECATED or INTERNAL.
To facilitate this at the definition level, extend the boolean and uint8_t property macros (as the examples) to accept variable arguments (VA_ARGS). This allows callers to optionally specify flags in the property definition.
Example:
DEFINE_PROP_UINT8("version", IOAPICCommonState, version, IOAPIC_VER_DEF, .flags = OBJECT_PROPERTY_DEPRECATED),
In other places where we track deprecation in QEMU, we have not used a boolean flag. Instead we have used a "const char *deprecation_note" internally, which lets us provide a user facing message, to be printed out in the warn_report, informing them what to do instead (either the feature is entirely removed, or there is a better alternative). IMHO we should be following the same pattern for properties, as it is much more user friendly than just printing a totally generic message "XXXX is deprecated, stop using it"
Not entirely true. QAPI/QMP uses special feature flag @deprecated, i.e. a boolean. We cannot emit a "user facing message": QMP cannot transport warnings. We could at best log one, in the hope that the user finds it. But we don't. Instead the deprecation note is in the documentation. The deprecation flag is visible in QAPI/QMP introspection. Management application developers need this; see Peter Krempa's reply. QEMU can be configured to reject input that makes use of deprecated stuff, and to hide deprecated stuff in output. This is intended for "testing the future".
Yes, rich deprecation hint is better. I think this still depends on USER_SET - distinguish internal/external or not :-(.
Since when we mark a property as deprecated, its code remains in the code tree, and internal calls should not trigger warnings. Deprecation hints are intended to reminder external users.
This depends on where you put the deprecation check. IIUC, all the user facing codepaths for setting properties end up calling through object_set_properties_from_qdict, but internal codepaths don't use that.
This may well be true (I didn't check), but how can we ensure it remains true?
That method can check & emit the deprecation warnings, without us needing any explicit tracking of "user set" - the use context is derived from the codepath
With regards, Daniel
Not entirely true.
QAPI/QMP uses special feature flag @deprecated, i.e. a boolean.
We cannot emit a "user facing message": QMP cannot transport warnings. We could at best log one, in the hope that the user finds it. But we don't.
Instead the deprecation note is in the documentation.
The deprecation flag is visible in QAPI/QMP introspection. Management application developers need this; see Peter Krempa's reply.
QEMU can be configured to reject input that makes use of deprecated stuff, and to hide deprecated stuff in output. This is intended for "testing the future".
I think a way is to add 'deprecated' flag (bool) in ObjectPropertyInfo, just like CpuDefinitionInfo did. Then only when property has a deprecation_note string, the 'deprecated' flag will be set for QAPI/QMP query.
Yes, rich deprecation hint is better. I think this still depends on USER_SET - distinguish internal/external or not :-(.
Since when we mark a property as deprecated, its code remains in the code tree, and internal calls should not trigger warnings. Deprecation hints are intended to reminder external users.
This depends on where you put the deprecation check. IIUC, all the user facing codepaths for setting properties end up calling through object_set_properties_from_qdict, but internal codepaths don't use that.
This may well be true (I didn't check), but how can we ensure it remains true?
Perhaps this interface requires documentation - and strongly caution that it *should not* be used for internal calls. Might this help prevent potential misuse? Thanks, Zhao
participants (4)
-
Daniel P. Berrangé -
Igor Mammedov -
Markus Armbruster -
Zhao Liu