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.
After some IRC chatter with Osier, I think that omitting an
unsupported parameter is better than hard-coding its value to
a default. It is easier to always reject an unknown parameter
by name than it is to conditionally reject setting a parameter
based on whether its value matches the default.
That said...
> > - * 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.
We still need a v2 that rejects unsupported parameters rather than
silently ignoring them. Remember, the way virsh and python
bindings work their 'set' functions is by first doing a 'get'
to see _which_ parameters can be set in the first place; so as
long as the 'get' function omits an unsupported parameter, then
the 'set' function is less likely to encounter an attempt to
change the unsupported parameter.