Re: [RFC 02/10] qom: Add basic object property deprecation hint support

[Zhao Liu <zhao1.liu@intel.com>]

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