Re: Semantic of xenUnifiedType()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]