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

[Nikunj A. Dadhania]

On Tue, 21 Sep 2010 18:12:29 +0100, "Daniel P. Berrange" <berrange at 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 at 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