Re: [libvirt] [PATCH 02/12] Adding structure for virDomainSetMemoryParameter

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(a)linux.vnet.ibm.com&gt; > --- > 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

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"

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