On Tue, 21 Sep 2010 18:12:29 +0100, "Daniel P. Berrange" <berrange@redhat.com> wrote:
On Mon, Sep 20, 2010 at 02:15:23PM +0530, Nikunj A. Dadhania wrote:
This patch adds a structure virMemoryParameter, it contains the name of the parameter and the type of the parameter along with a union.
Signed-off-by: Nikunj A. Dadhania <nikunj@linux.vnet.ibm.com> --- include/libvirt/libvirt.h.in | 51 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 51 insertions(+), 0 deletions(-)
+typedef struct _virMemoryParameter virMemoryParameter; + +struct _virMemoryParameter { + char field[VIR_DOMAIN_MEMORY_FIELD_LENGTH]; /* parameter name */ + int type; /* parameter type */ + union { + int i; /* data for integer case */ + unsigned int ui; /* data for unsigned integer case */ + long long int l; /* data for long long integer case */ + unsigned long long int ul; /* data for unsigned long long integer case */ + double d; /* data for double case */ + char b; /* data for char case */ + } value; /* parameter value */ +};
With the schedular parameters API we gave up and decided that each HV would be different for 'field', so used string parameters. I wonder if we could use an enum for memory parameters, or keep this char[] as extensible for HV specific memory tuning params? Perhaps its worth keeping like this just for consistent usage with _virSchedParameter
I agree, keeping the string would not limit any HVs from adding new parameters that are specific to some HV.
If we keep strings, then we should probably #define some constants for the well-known tunables.
eg #define VIR_DOMAIN_MEMORY_MAX_BALLOON "max-balloon" Sure, I will take care of this.
Oh, BTW this patch should be merged with the previous patch. The idea with a series of patches, is that the code should successfully compile after each individual patch is applied. The previous patch has a compile time dependancy on this patch, thus they need merging, or reversing in order
Thanks, did not know this trivia. I will reverse the order. Nikunj