Re: Semantic of xenUnifiedType()

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

 



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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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