[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |