On 06/14/2011 03:16 AM, Daniel P. Berrange wrote:
On Tue, Jun 07, 2011 at 10:03:36AM +0900, Minoru Usui wrote:
> virNodeGetMemoryStats: Expose new API
>
> Signed-off-by: Minoru Usui <usui(a)mxm.nes.nec.co.jp>
> ---
> include/libvirt/libvirt.h.in | 78 ++++++++++++++++++++++++++++++++++++++++++
> src/libvirt_public.syms | 1 +
> 2 files changed, 79 insertions(+), 0 deletions(-)
> +/**
> + * virMemoryStats:
> + *
> + * a virMemoryStats is a structure filled by virNodeGetMemoryStats()
> + * and providing the information of the memory of the Node.
> + */
> +
> +typedef struct _virMemoryStats virMemoryStats;
> +
> +struct _virMemoryStats {
> + char field[VIR_MEMORY_STATS_FIELD_LENGTH];
> + unsigned long long value;
> +};
Hmm, we now have two structs with identical layout (a field name and a
ull value); should these be consolidated into a single struct? I guess
earlier discussion on this patch series decided not to reuse the
virTypedParameter union struct, as we are pretty much confident that
both cpu and memory stats will always be ull-only, and not need the
extra effort for distinguishing types. But now is the time to think
about it, before we lock ourselves into something with the 0.9.3 commit.
> +++ b/src/libvirt_public.syms
> @@ -453,6 +453,7 @@ LIBVIRT_0.9.2 {
> LIBVIRT_0.9.3 {
> global:
> virNodeGetCPUStats;
> + virNodeGetMemoryStats;
> } LIBVIRT_0.9.2;
Indentation went wrong here, but ACK if that is fixed
Pushed with this squashed in:
diff --git i/python/generator.py w/python/generator.py
index d929efa..a14b9ce 100755
--- i/python/generator.py
+++ w/python/generator.py
@@ -364,6 +364,7 @@ skip_impl = (
'virDomainRevertToSnapshot',
'virDomainSendKey',
'virNodeGetCPUStats',
+ 'virNodeGetMemoryStats',
)
diff --git i/src/libvirt_public.syms w/src/libvirt_public.syms
index 1a97241..362dbed 100644
--- i/src/libvirt_public.syms
+++ w/src/libvirt_public.syms
@@ -455,7 +455,7 @@ LIBVIRT_0.9.3 {
virDomainPinVcpuFlags;
virDomainSendKey;
virNodeGetCPUStats;
- virNodeGetMemoryStats;
+ virNodeGetMemoryStats;
} LIBVIRT_0.9.2;
# .... define new API here using predicted next version number ....
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org