[Libvir] Repository for work-in-progress storage patches
Richard W.M. Jones
rjones at redhat.com
Sat Jan 19 14:37:51 UTC 2008
Daniel P. Berrange wrote:
> On Fri, Jan 18, 2008 at 07:55:35PM +0000, Daniel P. Berrange wrote:
>> On Fri, Jan 18, 2008 at 07:44:41PM +0000, Richard W.M. Jones wrote:
>>> A few comments:
>>>
>>> You should put #include <config.h> at the very top of all your C files
>>> (before any other headers/defines), to avoid warnings.
>>>
>>> There was one place where you'd used virFreeStoragePool, which should be
>>> virStoragePoolFree.
>>>
>>> Functions such as 'virDomainDestroy' have changed their semantics in
>>> that they now free the virDomainPtr object. I understand why you do
>>> this (the domain no longer exists, so the object cannot be used), but it
>>> is a big change from the p.o.v. of those of us using proper garbage
>>> collection, and moreover it's an ABI change. Existing correct code
>>> which did 'virDomainDestroy (dom); virDomainFree (dom);' could now segfault.
>> No it isn't an ABI change. The virDomainDestroy method has always
>> behaved this way. I simply moved the calls to free out of the per
>> driver destroy method, and into the top level libvirt.c destroy
>> method to remove the need for drivers to re-implement this every
>> time.
>
> Actually, no I take that back. The qemu driver always did this. The Xen
> driver did not. So the QEMU driver is actually buggy. I'll remove this
> free'ing of virDomainPtr from virDomainDestroy and fix the QEMU driver.
Actually I think I'm getting confused now.
The current (in CVS) documentation for virDomainDestroy &
virNetworkDestroy documents that they free the object. So bug in the
Xen driver instead?
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/20080119/cfb84cc7/attachment-0001.bin>
More information about the libvir-list
mailing list