]> xenbits.xensource.com Git - libvirt.git/commit
hyperv: update hypervObject struct.
authorDawid Zamirski <dzamirski@datto.com>
Tue, 4 Apr 2017 22:26:07 +0000 (18:26 -0400)
committerMatthias Bolte <matthias.bolte@googlemail.com>
Sat, 8 Apr 2017 12:14:20 +0000 (14:14 +0200)
commit87f2bd3c0cc92eb20f92b73c4701c457eb3eda9a
tree8a0a867a5701c7eea221fee391fd488170aaee1c
parenta5689ad2dc5e139da5696cdd6c1c558f7772cf01
hyperv: update hypervObject struct.

Currently named as hypervObjecUnified to keep code
compilable/functional until all bits are in place.

This struct is a result of unserializing WMI request response.
Therefore, it needs to be able to deal with different "versions" of the
same WMI class. To accomplish this, the "data" member was turned in to
a union which:

* has a "common" member that contains only WMI class fields that are
  safe to access and are present in all "versions". This is ensured by
  the code generator that takes care of proper struct memory alignment
  between "common", "v1", "v2" etc members. This memeber is to be used
  by the driver code wherever the API implementation can be shared for
  all supported hyper-v versions.
* the "v1" and "v2" member can be used by the driver code to handle
  version specific cases.

Example:

Msvm_ComputerSystem *vm = NULL;
...
hypervGetVirtualMachineList(priv, wqlQuery, *vm);
...
/* safe for "v1" and "v2" */
char *vmName = vm->data.common->Name;

/* or if one really needs special handling for "v2" */
if (priv->wmiVersion == HYPERV_WMI_VERSION_V2) {
    char *foo = vm->data.v2->SomeV2OnlyField;
}

In other words, driver should not concern itself with existence of "v1"
or "v2" of WMI class unless absolutely necessary.
src/hyperv/hyperv_wmi.h