On Tue, 21 Sep 2010 18:12:29 +0100, "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
> > ---
> > 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list