On Wed, 11 Feb 2026 16:58:47 +0000 Daniel P. Berrangé <[email protected]> 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é" <[email protected]> > > > 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
