[libvirt] [PATCH 1/2] node_memory: Do not fail if there is parameter unsupported
eblake at redhat.com
Tue Nov 27 16:11:26 UTC 2012
> On 2012年11月22日 11:14, Osier Yang wrote:
> > It makes no sense to fail the whole command if there is parameter
> > unsupported by the kernel. This patch fixes it by ignoring the
> > unsupported parameter for getMemoryParameters, and ignoring the
> > unsupported parameter for setMemoryParameters too if there are
> > more than one parameters to set, otherwise error out.
I'm not sure I agree with these semantics.
> > *
> > - * Get all node memory parameters. On input, @nparams gives the
> > size
> > - * of the @params array; on output, @nparams gives how many slots
> > were
> > - * filled with parameter information, which might be less but will
> > - * not exceed the input value.
> > + * Get all node memory parameters (parameter unsupported by OS
> > will be
> > + * ignored). On input, @nparams gives the size of the @params
But is this really right, or shouldn't we at least be able to
fake things? If the OS doesn't support tuning a variable, then
we should return a hard-coded value for the default setting
of that variable (in relation to newer kernels that DO support
tuning), rather than omitting it altogether.
> > array;
> > + * on output, @nparams gives how many slots were filled with
> > parameter
> > + * information, which might be less but will not exceed the input
> > value.
> > *
> > * As a special case, calling with @params as NULL and @nparams
> > as 0 on
> > * input will cause @nparams on output to contain the number of
> > parameters
> > @@ -6811,7 +6811,9 @@ error:
> > * value nparams of virDomainGetSchedulerType)
> > * @flags: extra flags; not used yet, so callers should always
> > pass 0
> > *
> > - * Change all or a subset of the node memory tunables.
> > + * Change all or a subset of the node memory tunables. Tunable
> > + * unsupported by OS wll be ignored if @nparams is not 1,
I disagree. I think we should continue to error out on unrecognized
tunables; furthermore, we should error out up front (if the user
passes an array of 3 elements, where only the 2nd element is
unsupported, then we should NOT modify the first element; that is,
we should verify that all the elements are settable before making
any modification). It is a disservice to the user to ignore their
request for a change.
And if you go with my approach that getting parameters should
return a hard-coded value rather than omitting unsupported
tunables, then the user should be allowed to pass the default
value of that tunable; the only thing they cannot do is
pass a non-default value.
More information about the libvir-list