Collin Walling <wall...@linux.ibm.com> writes: > On 7/25/24 3:39 AM, David Hildenbrand wrote: >> On 25.07.24 09:35, Markus Armbruster wrote: >>> Markus Armbruster <arm...@redhat.com> writes:
[...] >>>> Arguments that are silently ignored is bad interface design. >>>> >>>> Observe: when CpuModelInfo is an argument, @deprecated-props is always >>>> ignored. When it's a return value, absent means {}, and it can be >>>> present only for certain targets (currently S390). >>>> >>>> The reason we end up with an argument we ignore is laziness: we use the >>>> same type for both roles. We can fix that easily: >>>> >>>> { 'struct': 'CpuModel', >>>> 'data': { 'name': 'str', >>>> '*props': 'any' } } >>>> >>>> { 'struct': 'CpuModelInfo', >>>> 'base': 'CpuModel', >>>> 'data': { '*deprecated-props': ['str'] } } >>>> >>>> Use CpuModel for arguments, CpuModelInfo for return values. >>>> >>>> Since @deprecated-props is used only by some targets, I'd make it >>>> conditional, i.e. 'if': 'TARGET_S390X'. >>> >>> If we want just query-cpu-model-expansion return deprecated properties, >>> we can instead move @deprecated-props from CpuModelInfo to >>> CpuModelExpansionInfo. >> >> That might a bit more sense, because deprecated-props does not make any >> sense as input parameter, for example. > > Will do. Thanks for the feedback. v4 in the works. We better get this into 9.1. Plan B: mark @deprecated-props unstable to avoid backward compatibility pain.