On 01/24/2012 05:07 AM, Guan Nan Ren wrote:
>> static PyObject *
>> +libvirt_virDomainSetNumaParameters(PyObject *self ATTRIBUTE_UNUSED,
>> + PyObject *args) {
>
>> + LIBVIRT_BEGIN_ALLOW_THREADS;
>> + i_retval = virDomainGetNumaParameters(domain, params, &nparams, flags);
>> + LIBVIRT_END_ALLOW_THREADS;
>
> Why are we getting the existing parameters, instead of just blindly
> constructing params based on args? I think that's a waste of effort,
> considering that libvirt will already reject things if the user passes
> in unknown key names.
I finally realized _why_ we do it - that's because we want to pass the
correct types to libvirt.c, but python is not strongly typed. That is,
if libvirt is expecting a particular named value to be
VIR_TYPED_PARAM_ULLONG, but the python code passes '1', we should be
able to properly convert that python value to C's 1ULL, rather than
rejecting the python code for using an incorrect type, since there is
not quite a notion of incorrect type in python.
That means that either we hard-code the list of all known parameter
names and their type, or we make things done via a runtime query by
getting all parameters to learn their types before formatting the user's
settings back into something that libvirt will parse.
It may also mean that libvirt itself should be a bit nicer about things
- now that we have virTypedParam.c, maybe that function should be taught
to do some type conversions (if the user passes in VIR_TYPED_PARAM_INT,
but the code wanted VIR_TYPED_PARAM_ULLONG, libvirt could do the type
conversion on the user's behalf); if libvirt is made smarter, then the
python glue code might be simpler. But there's still the issue of
back-compat - a newer python library talking to an older libvirt that
didn't do automatic type conversion would still be stuck needing to
query for types first.
--
Eric Blake eblake@xxxxxxxxxx +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list