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.