On Thu, Feb 12, 2026 at 11:25:17PM +0800, Zhao Liu wrote: > 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).
There's a significant different there. Emitting deprecation messages in the API entry points tied to user data is a clear purpose, not open to abuse. Recording the difference between user set & internally set against the object instance persistently is an open ended purpose and based on what we've seen in QEMU in the past, that is highly likely to be mis-used. The idea of supporting deprecations on properties is definitely something we should do, but I really dn't want to see that expressed via the 'user set' mechanism from this series. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
