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 <[email protected]>
> 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 <[email protected]> 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 <[email protected]>
> > ---
> > 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
