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@xxxxxxxxxx> > --- > 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list