On Fri, Jan 02, 2026 at 01:06:01PM +0100, Igor Mammedov wrote:
Date: Fri, 2 Jan 2026 13:06:01 +0100 From: Igor Mammedov <imammedo@redhat.com> Subject: Re: [RFC 02/10] qom: Add basic object property deprecation hint support X-Mailer: Claws Mail 3.11.1-67-g0d58c6-dirty (GTK+ 2.24.21; x86_64-apple-darwin14.0.0)
On Wed, 3 Dec 2025 01:04:54 +0800 Zhao Liu <zhao1.liu@intel.com> wrote:
Now the common (but a bit fragmented) way to mark a property deprecated is to add the warning in its accssors.
But this is pretty inconvenient for such qdev properties, which are defined via DEFINE_PROP_* macros in the Property array. For qdev properties, their accessors are provided by pre-defined PropertyInfo, so that it's possible to modify PropertyInfo for a single "deprecated" property.
Then it's necessary to introduce property flags to mark some properties as deprecated, and to check the property flags when set the property, thereby to print a deprecation warning.
This not only benefits traditional qdev properties but also helps the deprecation of generic objects.
Note, internal attempt (except the compat case) should not trigger the deprecation warning but external user should see the deprecation information. Whether to perform deprecation checks based on property flags is controlled by the newly added "check" argument in object_property_try_add_full().
I'd split deprecation warning out for this patch, i.e. make this one "add per object instance flags", and take care of deprecation stuff on top,
Yeah, will do.
Also, API likely would need set/get/clear calls to operate on object flags.
I see, for dynamic flags ("user set" - you mentioned), these APIs are necessary. Will add something like object_property_[set|get|clear]_flags.
In subsequent work, the "check" option will be enabled for specific external property setting paths.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> --- include/qom/object.h | 72 ++++++++++++++++++++++++++++++++++++++++++++ qom/object.c | 72 +++++++++++++++++++++++++++++++++++--------- 2 files changed, 130 insertions(+), 14 deletions(-)
diff --git a/include/qom/object.h b/include/qom/object.h index 3f807a03f5aa..8f4c2f44d835 100644 --- a/include/qom/object.h +++ b/include/qom/object.h @@ -86,6 +86,12 @@ typedef void (ObjectPropertyRelease)(Object *obj, */ typedef void (ObjectPropertyInit)(Object *obj, ObjectProperty *prop);
+typedef enum ObjectPropertyFlags { + OBJECT_PROPERTY_NO_FLAGS = 0, + OBJECT_PROPERTY_DEPRECATED = 1 << 0,
maybe use BIT() instead of manual shift?
Sure, will do.
addidtionally given you are going to distinguish external vs internal, perhaps add flags 'default' and 'user set', I think the both could be used to cleanup cpu flags handling where we rely on setting/checking magic numbers to figure out where value comes from.
Good idea. I think a "user set" flag is enough. Considerring a property may be set multiple timers. In object_property_set_full(), we could add the "user set" flag for external setting and clear that flag for internal setting, then property's set accessor could know whether the value is from user or not.
+ OBJECT_PROPERTY_FULL_FLAGS = OBJECT_PROPERTY_DEPRECATED, +} ObjectPropertyFlags; + struct ObjectProperty { char *name; @@ -98,6 +104,7 @@ struct ObjectProperty ObjectPropertyInit *init; void *opaque; QObject *defval; + uint8_t flags; };
/** @@ -1090,6 +1097,41 @@ ObjectProperty *object_property_try_add(Object *obj, const char *name, ObjectPropertyRelease *release, void *opaque, Error **errp);
+/** + * object_property_try_add_full:
what's the reason for adding _full flavour over just modifying existing API?
I was previously concerned about making too many changes to other parts, but after re-checking, directly extending the current object_property_try_add() is better — there's not too many changes. Thanks for the reminder. Regards, Zhao