> 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".
I think a way is to add 'deprecated' flag (bool) in ObjectPropertyInfo, just like CpuDefinitionInfo did. Then only when property has a deprecation_note string, the 'deprecated' flag will be set for QAPI/QMP query. > >> 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? Perhaps this interface requires documentation - and strongly caution that it *should not* be used for internal calls. Might this help prevent potential misuse? Thanks, Zhao
