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

From: Ian Campbell <ian.campbell@citrix.com>
To: Doug Goldstein <cardoe@cardoe.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>, Tim Deegan <tim@xen.org>
Subject: Re: [PATCH 0/4] Allow schedulers to be selectable through Kconfig
Date: Wed, 6 Jan 2016 14:45:41 +0000	[thread overview]
Message-ID: <1452091541.21055.58.camel@citrix.com> (raw)
In-Reply-To: <567448E9.2030702@cardoe.com>

On Fri, 2015-12-18 at 11:56 -0600, Doug Goldstein wrote:
> In the end I really see the primary people that build Xen on their own
> as project maintainers (XenServer, Qubes, OpenXT) or distro maintainers
> (Ubuntu, Debian, Gentoo, Yocto) or "expert" users. Most people will use
> Xen as it comes packaged for them already and the Kconfig changes give
> the project/distro/experts the flexibility they need to build up Xen
> without maintaining downstream patches. So these won't really be shiny
> knobs for users to twiddle.

In this context I would consider the distro maintainers (at least for
generic, non-Xen specialised distros, e.g. XenServer and QUBES don't fit
here) to be users.

I don't think we want such distros to all be shipping subtly varying
versions of Xen any more than I want individual end users to be doing so.
Users of community (rather than Enterprise/Commercial) distros use many of
our upstream resources, including reporting bugs on xen-users and -devel.

But of course you (quite naturally, I think) expect that they will want to
play with these things, and I think that they will be no less prone to
fiddling with the shiny nobs than a individual user would be.

I don't want to distro users coming to use for support because they tried
to follow http://wiki.xenproject.org/wiki/Credit2_Scheduler_Development#Usi
ng_Credit2 and it didn't work, only to find that their distro has decided
to turn off credit2 in the packages, for whatever random reason the package
maintainer had.

I don't see this as contrary to your stated goals (e.g. ripping out all the
other schedulers), but I consider you to be within the expert camp for
wanting to do so (and having the chops to handle whatever pieces you find
yourselves with). I have no objections at all to allowing experts such as
yourselves to configure things and I applaud you for doing this in an
upstream way (it is the right thing to do).

My concern is that while you rightly consider yourselves expert enough and
are building something for a specific (and AIUI targeted) use case many
normal users tend to think that if they are expert enough to find and flip
the switch then they are expert enough to deal with the consequences, when
they are not and/or they do not have the specific use case which the switch
was added to support i.e. they want common or garden Xen and we want that
to mean the same for everyone.

It's those people (including general purpose distro maintainers) who I
think need to be strongly discouraged from messing with these options
because there will be a strong gravity towards them doing so.

> What provides the defaults that users should use are the defconfig
> files. The reason this doesn't work out so well for Linux is that there
> are really not defaults that work for everyone.

... and sadly by switching Xen to Kconfig this expectation _is_ going to
flow over to us, once someone sees "make menuconfig" mentioned somewhere
they are going to get their Linux head on and start messing with it.

>  But on the flip
> side of the coin Ian Campbell has been helping Debian to upstream
> changes they need [2].

BTW, I'm also a Debian Developer (although not the Xen package maintainer),
so I am doing this with as much downstream as upstream hat on.

Ian.

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