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

Re: [Xen-devel] [PATCH 0/4] Allow schedulers to be selectable through Kconfig



On Fri, 2015-12-18 at 12:08 +0100, Juergen Gross wrote:
> On 18/12/15 11:45, Ian Campbell wrote:
> > On Thu, 2015-12-17 at 14:59 -0600, Jonathan Creekmore wrote:
> > > Add machinery to allow the schedulers to be individually selectable
> > > through the Kconfig interface.
> > 
> > So I don't want to pick on this series or schedulers specifically here,
> > but
> > instead discuss the general premise of configurability of hypervisor
> > binaries, and this happens to be the first. I'm CCing Doug and "THE
> > REST"
> > from MAINTAINERS
> > 
> > Currently (even with the current switch to Kconfig thus far) we have a
> > fairly small and manageable set of configurations which any given Xen
> > binary can be in and in terms of what users are actually running an
> > even
> > smaller set I believe, most users fiddle with zero options and a small
> > number with one or two. I'd hazard a guess that the vast majority of
> > Xen
> > binaries are using a single config today and that the second place is a
> > fairly distant second.
> > 
> > This means we have avoided the combinatorial explosion of configuration
> > options which Linux suffers from (which result in things like
> > randconfig
> > build robots because no one can keep track of it all).
> > 
> > Just to be clear: I'm not at all opposed to more configurability for
> > expert
> > users who have specific usecases, know what they are doing and are
> > willing
> > to take responsibility for developments deviating form the norm.
> > 
> > However I am very wary of putting shiny looking nobs in front of the
> > average user, since they will find them and they will inevitably play
> > with
> > them and we will end up in the situation where every bug report
> > involves an
> > additional RTT while we ask for their .config (ok, in reality we'd
> > often
> > ask at the same time we inevitably have to ask for logs and other key
> > info,
> > so I guess I'm exaggerating, but still its a worry I think).
> > 
> > As well as support there is obviously a testing matrix impact.
> > 
> > How would people feel about a CONFIG_STANDARD_FEATURESET[0] with the
> > majority of tweakables depending on !STANDARD_FEATURESET? It would
> > default
> > Y with a help text which dissuades normal users from touching it ("Say
> > Y,
> > unless you are willing to pick up the pieces yourself. We do not
> > routinely
> > test or validate configurations without this option set. We expect you
> > to
> > offer to fix issues which you find. Beware of the leopard.").[1]
> 
> What I'd really like to see in the config options are things like:

Please can avoid getting derailed in to discussing the merits or otherwise
of particular potential configurables (and in particular whether they come
under standard/expert of not) for the time being.

(i.e. this is not, yet, a thread for everyone to list their own desires for
particular options)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.