[Libvir] Semantic of xenUnifiedType()
Richard W.M. Jones
rjones at redhat.com
Mon Dec 3 12:13:36 UTC 2007
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20071203/b2fbce5e/attachment-0001.bin>
More information about the libvir-list
mailing list