Re: [PATCH 1/2] node_memory: Do not fail if there is parameter unsupported

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]