Hi, Eric
On Fri, 01 Apr 2011 10:19:20 -0600
Eric Blake <eblake@xxxxxxxxxx> wrote:
> 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?
OK.
I'll change its user I/F like virDomainGetMemoryParameters(),
if it doesn't return absolute CPU time values.
> > +++ 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.
OK.
I'll change it.
>
> --
> Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
>
--
Minoru Usui <usui@xxxxxxxxxxxxxxxxx>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list