]> git.ipfire.org Git - thirdparty/libvirt.git/commit
capabilities: defaultConsoleTargetType can depend on architecture
authorViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Fri, 9 Nov 2012 15:00:36 +0000 (16:00 +0100)
committerEric Blake <eblake@redhat.com>
Fri, 9 Nov 2012 16:20:59 +0000 (09:20 -0700)
commitb1c88c14764e0b043a269d454a83a6ac7af34eac
tree0f3eec6a8f53155a97a0897de304933ba7dda5cd
parent02cf57c0d0d2333dceadb7f84b08ec28a35ef540
capabilities: defaultConsoleTargetType can depend on architecture

For S390, the default console target type cannot be of type 'serial'.
It is necessary to at least interpret the 'arch' attribute
value of the os/type element to produce the correct default type.

Therefore we need to extend the signature of defaultConsoleTargetType
to account for architecture. As a consequence all the drivers
supporting this capability function must be updated.

Despite the amount of changed files, the only change in behavior is
that for S390 the default console target type will be 'virtio'.

N.B.: A more future-proof approach could be to to use hypervisor
specific capabilities to determine the best possible console type.
For instance one could add an opaque private data pointer to the
virCaps structure (in case of QEMU to hold capsCache) which could
then be passed to the defaultConsoleTargetType callback to determine
the console target type.
Seems to be however a bit overengineered for the use case...

Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
21 files changed:
src/conf/capabilities.h
src/conf/domain_conf.c
src/esx/esx_driver.c
src/libxl/libxl_conf.c
src/lxc/lxc_conf.c
src/openvz/openvz_conf.c
src/parallels/parallels_driver.c
src/phyp/phyp_driver.c
src/qemu/qemu_capabilities.c
src/security/virt-aa-helper.c
src/test/test_driver.c
src/uml/uml_conf.c
src/vbox/vbox_tmpl.c
src/vmware/vmware_conf.c
src/xen/xen_hypervisor.c
src/xenapi/xenapi_driver.c
tests/testutilslxc.c
tests/testutilsqemu.c
tests/testutilsxen.c
tests/vmx2xmltest.c
tests/xml2vmxtest.c