(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
