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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/