[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]