[libvirt] [PATCH] Add node prefix to virNodeGet(CPU|Memory)Stats structs and defines

[Matthias Bolte]

2011/6/28 Daniel P. Berrange <berrange at redhat.com>:
> On Tue, Jun 28, 2011 at 01:51:29PM +0200, Matthias Bolte wrote:
>> 2011/6/15 Eric Blake <eblake at redhat.com>:
>> > On 06/15/2011 07:40 AM, Matthias Bolte wrote:
>> >> ---
>> >>  daemon/remote.c              |    4 +-
>> >>  include/libvirt/libvirt.h.in |   99 ++++++++++++++++++++----------------------
>> >>  src/driver.h                 |    4 +-
>> >>  src/libvirt.c                |   38 ++++++++--------
>> >>  src/nodeinfo.c               |   40 ++++++++--------
>> >>  src/nodeinfo.h               |    4 +-
>> >>  src/remote/remote_driver.c   |    4 +-
>> >>  tools/virsh.c                |   18 ++++----
>> >>  8 files changed, 103 insertions(+), 108 deletions(-)
>> >
>> > API change, but on an unreleased API.  Now's the time to do it, if we
>> > are in agreement :)
>> >
>> > The change is correct coding-wise, but I have a technical concern
>> > holding back my ack:
>> >
>> > Is there any chance that we might later add an API that can query CPU
>> > and Memory statistics of a domain, at which point, both
>> > virNodeGetCPUStats and virNodeGetMemoryStats could share the same
>> > vir{CPU,Memory}Stats structure with the theoretical virDomainGetCPUStats
>> > and virDomainGetMemoryStats?
>> >
>> > If so, then leaving things as-is for the common struct name makes sense.
>> >  If not, then the rename makes sense.  Thoughts?
>> >
>>
>> The release is near. If we want to do this we need to do it now.
>>
>> So, what do we do with this?
>
> ACK, lets merge it.
>
> With all the existing patches we're processing, I think we're going to
> have to add another release candidate before we cut 0.9.3, so lets get
> everything we want in.
>
> Daniel
>

As discussed also on IRC, we want to do this, so I pushed this patch now.

-- 
Matthias Bolte
http://photron.blogspot.com