(Sorry for the long silence — just returned from vacation.)
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.
Thank you for your explanation. In practice, as the alternative to USER_SET, I understand we identify the specific API entry points (including object_set_properties_from_qdict and others) and trigger the warning directly within those functions / code path, may I ask if this understanding is right? The current API entry points are somewhat fragmented; perhaps we should consider whether further unification is possible. Regards, Zhao