[Libvir] Semantic of xenUnifiedType()
It does the following: static const char * xenUnifiedType (virConnectPtr conn) { GET_PRIVATE(conn); int i; const char *ret; for (i = 0; i < XEN_UNIFIED_NR_DRIVERS; ++i) if (priv->opened[i] && drivers[i]->type) { ret = drivers[i]->type (conn); if (ret) return ret; } return NULL; } as a result if running as an user virConnectGetType() returns "XenXM" because the XM file parser backend ended up being registered first. I think that's bogus and we should change the function to return "Xen" in any case and drop the virDrvGetType type from struct xenUnifiedDriver and all associated functions in the various back-ends. Opinion ? Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Fri, Nov 30, 2007 at 10:55:37AM -0500, Daniel Veillard wrote:
It does the following:
static const char * xenUnifiedType (virConnectPtr conn) { GET_PRIVATE(conn); int i; const char *ret;
for (i = 0; i < XEN_UNIFIED_NR_DRIVERS; ++i) if (priv->opened[i] && drivers[i]->type) { ret = drivers[i]->type (conn); if (ret) return ret; }
return NULL; }
as a result if running as an user virConnectGetType() returns "XenXM" because the XM file parser backend ended up being registered first. I think that's bogus and we should change the function to return "Xen" in any case and drop the virDrvGetType type from struct xenUnifiedDriver and all associated functions in the various back-ends.
Opinion ?
Yes, it should always return 'Xen' - calling out to individual backends is pointless - the fact that there are multiple delegations inside the Xen unified driver, is an implementation detail which shouldn't leak out. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Fri, Nov 30, 2007 at 03:59:29PM +0000, Daniel P. Berrange wrote:
On Fri, Nov 30, 2007 at 10:55:37AM -0500, Daniel Veillard wrote:
It does the following:
static const char * xenUnifiedType (virConnectPtr conn) { GET_PRIVATE(conn); int i; const char *ret;
for (i = 0; i < XEN_UNIFIED_NR_DRIVERS; ++i) if (priv->opened[i] && drivers[i]->type) { ret = drivers[i]->type (conn); if (ret) return ret; }
return NULL; }
as a result if running as an user virConnectGetType() returns "XenXM" because the XM file parser backend ended up being registered first. I think that's bogus and we should change the function to return "Xen" in any case and drop the virDrvGetType type from struct xenUnifiedDriver and all associated functions in the various back-ends.
Opinion ?
Yes, it should always return 'Xen' - calling out to individual backends is pointless - the fact that there are multiple delegations inside the Xen unified driver, is an implementation detail which shouldn't leak out.
Okay, agreed, cleaned up in CVS, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel P. Berrange wrote:
On Fri, Nov 30, 2007 at 10:55:37AM -0500, Daniel Veillard wrote:
It does the following:
static const char * xenUnifiedType (virConnectPtr conn) { GET_PRIVATE(conn); int i; const char *ret;
for (i = 0; i < XEN_UNIFIED_NR_DRIVERS; ++i) if (priv->opened[i] && drivers[i]->type) { ret = drivers[i]->type (conn); if (ret) return ret; }
return NULL; }
as a result if running as an user virConnectGetType() returns "XenXM" because the XM file parser backend ended up being registered first. I think that's bogus and we should change the function to return "Xen" in any case and drop the virDrvGetType type from struct xenUnifiedDriver and all associated functions in the various back-ends.
Opinion ?
Yes, it should always return 'Xen' - calling out to individual backends is pointless - the fact that there are multiple delegations inside the Xen unified driver, is an implementation detail which shouldn't leak out.
Yes, agreed too. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones