Re: Semantic of xenUnifiedType()

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

 



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  -=| 

--
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]