[libvirt] [PATCH 1/6] virNodeGetCpuTime: Expose new API

[Eric Blake]

On 03/31/2011 07:55 PM, Minoru Usui wrote:
> virNodeGetCpuTime: Expose new API
> 
>  include/libvirt/libvirt.h.in |   26 ++++++++++++++++++++++++++
>  src/libvirt_public.syms      |    1 +
>  2 files changed, 27 insertions(+), 0 deletions(-)

>  
> +/**
> + * virNodeCpuTime:
> + *
> + * a virNodeCpuTime is a structure filled by virNodeGetCpuTime() and providing
> + * the information for the cpu time of Node.
> + */
> +
> +typedef struct _virNodeCpuTime virNodeCpuTime;
> +
> +struct _virNodeCpuTime {
> +    unsigned long long user;
> +    unsigned long long system;
> +    unsigned long long idle;
> +    unsigned long long iowait;
> +};

Can we portably get all of this information on Windows?  If not, how do
you express which values we don't know how to obtain?

> @@ -593,6 +616,9 @@ int                     virNodeGetInfo          (virConnectPtr conn,
>                                                   virNodeInfoPtr info);
>  char *                  virConnectGetCapabilities (virConnectPtr conn);
>  
> +int                     virNodeGetCpuTime       (virConnectPtr conn,
> +                                                 virNodeCpuTimePtr cpu_time);
> +

Rather than locking ourselves into yet another inflexible API (no flags
parameter and a hard-coded struct means no way to extend this if we ever
come up with some new stat to query), should we instead be following the
lead of getMemoryParameters which takes a typed-name/value array to pass
an arbitrary number of parameters, which allows extension without a new API?

> +++ b/src/libvirt_public.syms
> @@ -434,6 +434,7 @@ LIBVIRT_0.9.0 {
>          virEventRunDefaultImpl;
>          virStorageVolDownload;
>          virStorageVolUpload;
> +        virNodeGetCpuTime;
>  } LIBVIRT_0.8.8;

While I think that something along the lines of this API is appropriate
for libvirt (indeed, knowing a host's CPU utilization can indeed be a
factor for upper-level management software in deciding whether to
migrate another domain on or off of the machine), it's too late to put
it into 0.9.0.  We'd be setting bad precedent by accepting this after
the first release candidate did a feature freeze, so you'd need to
adjust this to 0.9.1.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110401/5bbe4615/attachment-0001.sig>