[libvirt] [PATCH 1/2] node_memory: Do not fail if there is parameter unsupported
Eric Blake
eblake at redhat.com
Tue Nov 27 16:53:53 UTC 2012
> 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.
More information about the libvir-list
mailing list