ping
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
s/ignored/omitted/ 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,
w/wll/will/ 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.