[Libvir] A couple of questions about the Python bindings
Daniel P. Berrange
berrange at redhat.com
Tue Mar 27 13:44:13 UTC 2007
On Tue, Mar 27, 2007 at 12:58:08PM +0100, Richard W.M. Jones wrote:
> virDomainGetUUIDString,
> virDomainPinVcpu,
> virNetworkGetUUIDString:
>
> These functions don't seem to check whether the parameters are
> correct. For example, virDomainGetUUIDString doesn't check if the
> buffer parameter passed from Python is large enough to take the UUID string.
>
> virDomainPinVcpu is just plain strange (but I guess that strangeness
> eminates from the Xen implementation), but it seems possible for the
> Python code to be wrong about the length of the Vcpu map (string).
> Shouldn't the length be taken from the string itself?
I'm pretty sure all 3 of those methods will need to be hand-written rather
than letting the generator do its thing. For the GetUUIDString() functions
the C prototype has the caller pass in a pre-allocate char * - which is
getting translated in Python as the caller passing in a string object. This
is dumb from the python POV where we have garbage collection. The Python
wrapper code should allocate the correct sized char * when calling the
GetUUIDString methods & then return a python string object. For the PingVCPU
method things are more complicated - in C its a large bit field, although it
is represented as a char *. In python I think we need to represent it as a
list of VCPU numbers.
> virDomainUndefine,
> virNetworkUndefine:
>
> It's unclear from the libvirt documentation, but it sounds as if
> these functions invalidate (free) the virDomainPtr / virNetworkPtr
> object passed to them. (In fact, the Xen implementation of virDomainPtr
> at least _doesn't_ free it - is that a bug?) If this is the case, then
> the Python bindings ought to set self._o = None.
Yes, the virDomainPtr objects ought to be free'd by these two functions,
so the python should clear the _o member after the calls complete. It
should also clear it after virDomainDestroy if it doesn't already.
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 -=|
More information about the libvir-list
mailing list