From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [PATCH 0/4] Allow schedulers to be selectable through Kconfig Date: Fri, 18 Dec 2015 11:56:57 -0600 Message-ID: <567448E9.2030702@cardoe.com> References: <1450385974-12732-1-git-send-email-jonathan.creekmore@gmail.com> <1450435531.4053.196.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4479052207945965146==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1a9zH8-0005xm-LX for xen-devel@lists.xenproject.org; Fri, 18 Dec 2015 17:57:06 +0000 Received: by mail-yk0-f174.google.com with SMTP id 140so66526971ykp.0 for ; Fri, 18 Dec 2015 09:57:04 -0800 (PST) In-Reply-To: <1450435531.4053.196.camel@citrix.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: Ian Campbell , Jonathan Creekmore , xen-devel@lists.xenproject.org Cc: Keir Fraser , Ian Jackson , Jan Beulich , Tim Deegan List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============4479052207945965146== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BQpNUllU2RUISEjjpehmocTwbODALkxVI" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BQpNUllU2RUISEjjpehmocTwbODALkxVI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/18/15 4:45 AM, 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. >=20 > 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 RES= T" > from MAINTAINERS >=20 > 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 eve= n > 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 Xe= n > binaries are using a single config today and that the second place is a= > fairly distant second. >=20 > This means we have avoided the combinatorial explosion of configuration= > options which Linux suffers from (which result in things like randconfi= g > build robots because no one can keep track of it all). >=20 > Just to be clear: I'm not at all opposed to more configurability for ex= pert > users who have specific usecases, know what they are doing and are will= ing > to take responsibility for developments deviating form the norm. >=20 > 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 w= ith > them and we will end up in the situation where every bug report involve= s an > additional RTT while we ask for their .config (ok, in reality we'd ofte= n > ask at the same time we inevitably have to ask for logs and other key i= nfo, > so I guess I'm exaggerating, but still its a worry I think). >=20 > As well as support there is obviously a testing matrix impact. >=20 > How would people feel about a CONFIG_STANDARD_FEATURESET[0] with the > majority of tweakables depending on !STANDARD_FEATURESET? It would defa= ult > 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 routin= ely > test or validate configurations without this option set. We expect you = to > offer to fix issues which you find. Beware of the leopard.").[1] >=20 > I might even go so far as to suggest that !STANDARD_FEATURESET > configurations would not be subject to security support (i.e. issues wh= ich > can _only_ arise with that option disabled are't covered). >=20 > The bar for adding a new option which does not depend on > !STANDARD_FEATURESET would be _high_. >=20 > Ian. >=20 > [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? >=20 > http://www.goodreads.com/quotes/40705-but-the-plans-were-on-dis= play-on-display-i-eventually >=20 > ;-) >=20 So I know this is going to be a thread hijack but I think its important for me to explain where Jonathan Creekmore and I are coming from with our recently submitted patches. We recently took over a project based on an old version of Xen that has a lot of customization. Part of our goal was to understand those modifications and re-implement them in a fashion that would be acceptable to upstream. So for example in the code base we worked with all other schedulers were entirely ripped out of the code base. Jonathan has reworked this to make it possible to disable each scheduler independently. Additionally Jonathan improved the way that extra schedulers can be added in the future. Effectively we want to engage the Xen community as much as possible and come up with solutions that are workable for the community as well as our needs. Now here's why I believe in this approach. I've looked at some of the other XenProject derived projects (e.g. XenServer, Qubes, OpenXT) and Linux distros shipping Xen (Ubuntu, Debian, Gentoo, Yocto, etc) and I saw that they all contain a number of patches against XenProject. To me this weakens the overall project by everyone maintaining their own fork. Everyone's goal should be to work on upstreaming changes in a fashion that is acceptable to the community in an agnostic fashion. Recently I took Joanna Rutkowska to task for not contributing work upstream and maintaining downstream changes and expecting Xen to confirm to her project's needs [1]. But on the flip side of the coin Ian Campbell has been helping Debian to upstream changes they need [2]. 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. 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. I believe for a long time the x86_64 defconfig was a setup for Linus' development laptop and most of the other arches defconfigs were setup for their respective maintainers as well. But in the case of Xen the defconfig will be the defaults and we don't even require the user to run `make *config` so it really is more of an "expert" option already vs Linux where you must first run `make *config` before building your kernel. [1] http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg00813.html= [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D805508 --=20 Doug Goldstein --BQpNUllU2RUISEjjpehmocTwbODALkxVI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWdEjsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUokcP/iB3oyiuTGGnuYmiPzTRmSBl qh8nCLFGCut5T9Qk0kKK/45pQAas7VQe579tNWR5AxIFzPW7eqbnI8VAAPF8VBio 0PenJJv6tHEorR6O+5GIVr8DCPAqbGOYNIOV9ZIauWXUE6qVI/r743f7ubFdNeoM Dy+54XXC0Wmt5+bf2lGFOkxVw+qWCwSlKJSQqacUrWE4xuBv44ACGYFMMCSugGFn pYFnLzfpF04hTWMuFZk6Wquyz330vN3NjhzU34NfZuT40ROOKTz9+/7I0AZo5WNf xxjMwx19rGBdUsjPQ2Vv9Lv9UU1DINcbLSr1GwvLOOtgad36L3/m6veSHGV/dNh3 yCzQs2SoM7yVLPZADGamSeOq0qZVVJC0VMWnBbn6fTfkJ0B9gYsh8NiltOB9PXWZ NEtfN40qPCY3sKwnvCLjTZ2uj9sdajFv188olYQnBZQA+ASa0ILlcTG9B4I6H+vb owxqJl7Y9HXgFinfXRaL6/IpTNAcUy19bEtmiimb4jwoQhVC1qj9OpAFxGeTnBPd VqTUfA6RUJ/yaGONoReq7aQMhc8//lShuuZX+odKMrA1J1MQL5l3QU4QqSxUT03c neFzLn2VqxFLpaok9S++7LXcYny7EqD8M45gdH3Fl9TON8TLGXaOMPBUUK+/SRRY m9f7PwyZzirmHsYX1EJF =FF2b -----END PGP SIGNATURE----- --BQpNUllU2RUISEjjpehmocTwbODALkxVI-- --===============4479052207945965146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4479052207945965146==--