On Fri, Sep 14, 2012 at 02:42:16PM +0800, Osier Yang wrote:
* src/rpc/gendispatch.pl: (virNodeSetMemoryParameters is the
the special one which needs a connection object as the first
argument, improve the generator to support it).
* daemon/remote.c: (Implement the server side handler for
virDomainGetMemoryParameters)
* src/remote/remote_driver.c: (Implement the client side handler
for virDomainGetMemoryParameters)
* src/remote/remote_protocol.x: (New RPC procedures for the two
new APIs and structs to represent the args and ret for it)
* src/remote_protocol-structs: Likewise
---
daemon/remote.c | 59 ++++++++++++++++++++++++++++++++++++++++++
src/remote/remote_driver.c | 50 +++++++++++++++++++++++++++++++++++
src/remote/remote_protocol.x | 24 ++++++++++++++++-
src/remote_protocol-structs | 20 ++++++++++++++
src/rpc/gendispatch.pl | 3 ++
5 files changed, 155 insertions(+), 1 deletions(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index 12cd25c..337acd8 100644
[...]
--- a/src/remote/remote_protocol.x
+++ b/src/remote/remote_protocol.x
@@ -229,6 +229,11 @@ const REMOTE_DOMAIN_GET_CPU_STATS_MAX = 2048;
*/
const REMOTE_DOMAIN_DISK_ERRORS_MAX = 256;
+/*
+ * Upper limit on number of memory parameters
+ */
+const REMOTE_NODE_MEMORY_PARAMETERS_MAX = 16;
+
Hum, it doesn't cost much to increase that a bit, on the other hand
if we hit the limit raising it becomes a deployment problem.
I would raise that arbitrarilly a bit higher (32 or 64) to avoid the
issue in the long term.
/* UUID. VIR_UUID_BUFLEN definition comes from libvirt.h */
typedef opaque remote_uuid[VIR_UUID_BUFLEN];
Looks fine otehrwise, ACK,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/