All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Juergen Gross <jgross@suse.com>,
	Jonathan Creekmore <jonathan.creekmore@gmail.com>,
	xen-devel@lists.xenproject.org
Cc: Keir Fraser <keir@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Doug Goldstein <cardoe@cardoe.com>, Tim Deegan <tim@xen.org>
Subject: Re: [PATCH 0/4] Allow schedulers to be selectable through Kconfig
Date: Fri, 18 Dec 2015 11:19:21 +0000	[thread overview]
Message-ID: <1450437561.4053.202.camel@citrix.com> (raw)
In-Reply-To: <5673E91C.2090102@suse.com>

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.

  reply	other threads:[~2015-12-18 11:20 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-17 20:59 [PATCH 0/4] Allow schedulers to be selectable through Kconfig Jonathan Creekmore
2015-12-17 20:59 ` [PATCH 1/4] build: Hook the schedulers into Kconfig Jonathan Creekmore
2015-12-18  1:35   ` Dario Faggioli
2015-12-18  2:20     ` Jonathan Creekmore
2015-12-18  9:19       ` Dario Faggioli
2015-12-18 10:52     ` George Dunlap
2015-12-18 11:23       ` Dario Faggioli
2015-12-18  8:57   ` Andrew Cooper
2015-12-18 16:43     ` Jonathan Creekmore
2015-12-17 20:59 ` [PATCH 2/4] build: Alloc space for sched list in the link file Jonathan Creekmore
2015-12-18  9:01   ` Andrew Cooper
2015-12-18 16:40     ` Jonathan Creekmore
2015-12-18 16:48       ` Andrew Cooper
2015-12-18 17:07         ` Jan Beulich
2015-12-18 17:10           ` Andrew Cooper
2015-12-18 17:11           ` Jonathan Creekmore
2015-12-18 17:23             ` Andrew Cooper
2015-12-17 20:59 ` [PATCH 3/4] sched: Register the schedulers into the list Jonathan Creekmore
2015-12-18  1:42   ` Dario Faggioli
2015-12-18  9:03   ` Andrew Cooper
2015-12-17 20:59 ` [PATCH 4/4] sched: Use the auto-generated list of schedulers Jonathan Creekmore
2015-12-18  1:47   ` Dario Faggioli
2015-12-18  9:12   ` Andrew Cooper
2015-12-18 16:44     ` Jonathan Creekmore
2015-12-18 10:50   ` Jan Beulich
2015-12-18 16:00     ` Jonathan Creekmore
2015-12-18 16:43       ` Jan Beulich
2015-12-18 17:24         ` Jonathan Creekmore
2015-12-18 17:30           ` Andrew Cooper
2015-12-18 10:39 ` [PATCH 0/4] Allow schedulers to be selectable through Kconfig Jan Beulich
2015-12-18 10:45 ` Ian Campbell
2015-12-18 10:58   ` Jan Beulich
2015-12-18 11:08   ` Juergen Gross
2015-12-18 11:19     ` Ian Campbell [this message]
2015-12-18 11:30     ` Jan Beulich
     [not found]     ` <5673FC6202000078000C122B@suse.com>
2015-12-18 11:41       ` Juergen Gross
2015-12-18 17:56   ` Doug Goldstein
2015-12-18 18:25     ` Andrew Cooper
2016-01-06 14:45     ` Ian Campbell
2016-01-07 14:01       ` Jonathan Creekmore
2016-01-07 14:37         ` Jan Beulich
2016-01-07 15:00           ` Ian Campbell
2016-01-07 15:18             ` Doug Goldstein
2016-01-07 15:31               ` Ian Campbell
2016-01-07 15:43               ` Jonathan Creekmore
2016-01-07 15:54                 ` Jan Beulich
2016-01-07 15:47               ` Jan Beulich
2016-01-07 15:30             ` Ian Campbell
2016-01-07 15:51               ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1450437561.4053.202.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=cardoe@cardoe.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=jonathan.creekmore@gmail.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.