On Fri, Jun 20, 2014 at 04:19:08PM +0200, Michal Privoznik wrote:
The API is supposed to fetch virEmulatorCapabilities once
implemented
in the hypervisor drivers.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
include/libvirt/libvirt.h.in | 6 +++++
src/driver.h | 7 ++++++
src/libvirt.c | 52 ++++++++++++++++++++++++++++++++++++++++++++
src/libvirt_public.syms | 2 ++
src/remote/remote_driver.c | 1 +
src/remote/remote_protocol.x | 19 +++++++++++++++-
src/remote_protocol-structs | 10 +++++++++
7 files changed, 96 insertions(+), 1 deletion(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index c83b20d..f71f732 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -1585,6 +1585,12 @@ int virNodeGetInfo (virConnectPtr
conn,
virNodeInfoPtr info);
char * virConnectGetCapabilities (virConnectPtr conn);
+char * virConnectGetEmulatorCapabilities(virConnectPtr conn,
+ const char *emulatorbin,
+ const char *machine,
+ const char *virttype,
+ unsigned int flags);
Following on from my prev comments lets call this virConnectGetDomainCapabilities
since it is really about the <domain> XML schema and it is conceivable for a virt
driver to not have any <emulator> at all.
Hmm, this reminds me that we should have 'const char *arch' in
there too. While for QEMU the architecture is implied by the emulator
binary path provided, this doesn't hold true for say VMWare which
doesn't use the emulator binary field.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|