> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list