On Fri, Mar 12, 2021 at 09:52:33AM +0100, Claudio Fontana wrote: > On 3/12/21 9:48 AM, Andrew Jones wrote: > > On Fri, Mar 12, 2021 at 09:11:45AM +0100, Thomas Huth wrote: > >> On 12/03/2021 08.42, Marc-André Lureau wrote: > >>> > >>> > >>> On Fri, Mar 12, 2021 at 3:14 AM Philippe Mathieu-Daudé > >>> <philmd@xxxxxxxxxx <mailto:philmd@xxxxxxxxxx>> wrote: > >>> > >> [...] > >>> +## > >>> +# @AcceleratorInfo: > >>> +# > >>> +# Accelerator information. > >>> +# > >>> +# @name: The accelerator name. > >>> +# > >>> +# Since: 6.0 > >>> +## > >>> +{ 'union': 'AcceleratorInfo', > >>> + 'base': {'name': 'Accelerator'}, > >>> + 'discriminator': 'name', > >>> + 'data': { } } > >>> > >>> + > >>> > >>> > >>> Making room for future details, why not. > >> > >> I think we definitely need the additional data section here: For KVM on > >> POWER, it would be good to know whether it's KVM-HV or KVM-PR, for KVM on > >> MIPS it would be good to know whether it's KVM_VM_MIPS_VZ or KVM_VM_MIPS_TE, > >> for KVM on x86 whether it's the AMD flavor or Intel, ... > > > > Could also pre-expand all of these and list them individually. > > > > Let us consider simplicity for the reader, and which use cases we expect for this. What do you mean by "reader"? If you mean the QMP client that needs this information, then I can't think of anything more simple than a single list of booleans with descriptive names to process. If you mean that the expected use cases don't care about all those variants, then you don't need to worry about that. Only the ones compiled in will be in the list. The expected use cases will never see the other ones. Thanks, drew
