[virt-tools-list] [PATCH 3] add parameter flags to D.get_cpu_stats()

Eric Blake eblake at redhat.com
Wed Apr 18 15:18:45 UTC 2012


On 04/18/2012 05:14 AM, Hu Tao wrote:
> ---
>  examples/get_cpu_stats.ml   |    2 +-
>  libvirt/libvirt.ml          |    2 +-
>  libvirt/libvirt.mli         |    2 +-
>  libvirt/libvirt_c_oneoffs.c |    9 +++++----
>  4 files changed, 8 insertions(+), 7 deletions(-)
> 
> +++ b/libvirt/libvirt_c_oneoffs.c
> @@ -532,20 +532,21 @@ extern int virDomainGetCPUStats (virDomainPtr domain,
>  #endif
>  
>  CAMLprim value
> -ocaml_libvirt_domain_get_cpu_stats (value domv, value nr_pcpusv)
> +ocaml_libvirt_domain_get_cpu_stats (value domv, value nr_pcpusv, value flagsv)

This adds flags support to the per-cpu half of the libvirt API, but you
are still missing ocaml bindings for the portion of the libvirt API that
accesses the domain total stats.  Also, I never understood why the
caller has to know how many cpus they are passing in advance - shouldn't
the bindings be smart enough to return an appropriately sized array that
covers all possible cpus without the caller having to pre-specify that
sizing?

For comparison, in the python bindings, we expressed things as:

    if (!PyArg_ParseTuple(args, (char *)"OOi:virDomainGetCPUStats",
                          &pyobj_domain, &totalbool, &flags))

so that a user passes in the domain; a choice of whether they want total
stats (pass true to get a 1-element array back, corresponding to the C
code passing start_cpu of -1), or per-cpu stats (pass fals to get an
n-element array back, with each element mapping to a cpu, and with the
array sized according to all cpus available); and finally a flags parameter.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20120418/0059c418/attachment.sig>


More information about the virt-tools-list mailing list