On 10/11/2016 03:22 AM, Markus Armbruster wrote:

> query-memory-devices returns a list of MemoryDeviceInfo:
> 
>     ##
>     # @MemoryDeviceInfo:
>     #
>     # Union containing information about a memory device
>     #
>     # Since: 2.1
>     ##
>     { 'union': 'MemoryDeviceInfo', 'data': {'dimm': 'PCDIMMDeviceInfo'} }
> 
> This is a union, designed to be extended for other types of memory
> device frontends.
> 
> Sadly, it's a "simple" union (I dislike those).
> 
> You could add a new member to be used for the NVDIMM case.  It would
> probably duplicate some or all of PCDIMMDeviceInfo, though.
> 
> If it needs all of PCDIMMDeviceInfo, you could make the new member's
> type have PCDIMMDeviceInfo as base.
> 
> If we can identify information *any* memory device frontend should have,
> the appropriate design would be a flat union with common information
> common, and type-specific information in union branches.  Could
> MemoryDeviceInfo be backward-compatibly morphed into such a type?

Yes, conversion to a flat union is possible without breaking existing
QMP usage.  It would look something like this (with anonymous base and
branch classes, which is still one of my pending qapi patches to post):

{ 'enum': 'MemoryDeviceType', 'data': [ 'dimm', 'nvdimm' ] }
{ 'union': 'MemoryDeviceInfo', 'base': { 'type': 'MemoryDeviceType' },
  'discriminator': 'type',
  'data': { 'dimm': { 'data': 'PCIMMDeviceInfo' },
            'nvdimm': 'whatever_type_here' } }

We would still have back-compatible:

{ "type": "dimm", "data": { "addr":..., "size":..., ... } }

for dimm, and for nvdimm, we would have

{ "type": "nvdimm", whatever fields we want here }

whether we want all the fields to be flattened in the nvdimm case, vs.
nested (for back-compat) under a 'data' dict in the 'dimm' case, or
whether we want both uses to be nested under a 'data' dict for
consistency, is a matter of taste.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org