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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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]

I might even go so far as to suggest that !STANDARD_FEATURESET
configurations would not be subject to security support (i.e. issues which
can _only_ arise with that option disabled are't covered).

The bar for adding a new option which does not depend on
!STANDARD_FEATURESET would be _high_.

Ian.

[0] I really mean CONFIG_STANDARD_CONFIG, but that sounds dumb. I don't
really intend for it to only control "features". CONFIG_STANDARD might be
an alternative.
[1] Hrm, CONFIG_LEOPARD?

        
http://www.goodreads.com/quotes/40705-but-the-plans-were-on-display-on-display-i-eventually

  ;-)

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