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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list