From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 0/4] Allow schedulers to be selectable through Kconfig Date: Fri, 18 Dec 2015 11:19:21 +0000 Message-ID: <1450437561.4053.202.camel@citrix.com> References: <1450385974-12732-1-git-send-email-jonathan.creekmore@gmail.com> <1450435531.4053.196.camel@citrix.com> <5673E91C.2090102@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1a9t5Z-00007W-Vo for xen-devel@lists.xenproject.org; Fri, 18 Dec 2015 11:20:46 +0000 In-Reply-To: <5673E91C.2090102@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Juergen Gross , Jonathan Creekmore , xen-devel@lists.xenproject.org Cc: Keir Fraser , Ian Jackson , Jan Beulich , Doug Goldstein , Tim Deegan List-Id: xen-devel@lists.xenproject.org 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.