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é" <berrange@redhat.com> 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é" <berrange@redhat.com> 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 :|