Daniel P. Berrangé <[email protected]> writes: > 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"
Not entirely true. QAPI/QMP uses special feature flag @deprecated, i.e. a boolean. We cannot emit a "user facing message": QMP cannot transport warnings. We could at best log one, in the hope that the user finds it. But we don't. Instead the deprecation note is in the documentation. The deprecation flag is visible in QAPI/QMP introspection. Management application developers need this; see Peter Krempa's reply. QEMU can be configured to reject input that makes use of deprecated stuff, and to hide deprecated stuff in output. This is intended for "testing the future". >> 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. This may well be true (I didn't check), but how can we ensure it remains true? > 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
