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