qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC QEMU PATCH 8/8] qmp: add a qmp command 'query-nvdi


From: Eric Blake
Subject: Re: [Qemu-devel] [RFC QEMU PATCH 8/8] qmp: add a qmp command 'query-nvdimms' to get plugged NVDIMM devices
Date: Tue, 11 Oct 2016 09:45:56 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]