From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [PATCH v4 2/5] build: Hook the schedulers into Kconfig Date: Mon, 11 Jan 2016 10:31:43 -0600 Message-ID: <5693D8EF.4080002@cardoe.com> References: <1452288166-43501-1-git-send-email-jonathan.creekmore@gmail.com> <1452288166-43501-3-git-send-email-jonathan.creekmore@gmail.com> <5693C52602000078000C56EF@prv-mh.provo.novell.com> <5693DBA702000078000C5851@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0541463566318464493==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aIfNo-0004rX-Lu for xen-devel@lists.xenproject.org; Mon, 11 Jan 2016 16:31:52 +0000 Received: by mail-yk0-f196.google.com with SMTP id a85so28172239ykb.2 for ; Mon, 11 Jan 2016 08:31:50 -0800 (PST) In-Reply-To: <5693DBA702000078000C5851@prv-mh.provo.novell.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: Jan Beulich , Jonathan Creekmore Cc: George Dunlap , xen-devel@lists.xenproject.org, Dario Faggioli , lars.kurth.xen@gmail.com List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============0541463566318464493== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bGVuVhK4puhNvbkhUmRuEFw4CTEhrXm6S" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bGVuVhK4puhNvbkhUmRuEFw4CTEhrXm6S Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/11/16 9:43 AM, Jan Beulich wrote: >>>> On 11.01.16 at 16:10, wrote: >> Jan Beulich writes: >>>>>> On 08.01.16 at 22:22, wrote: >>>> +config SCHED_CREDIT >>>> + bool "Credit scheduler support" >>>> + default y >>> >>> I continue to think that not making the primary scheduler configurabl= e >>> would be the better solution to the problems resulting from possibly >>> all of them getting turned off. >> >> Except that is completely contrary to my goal with this patchset (bein= g >> able to compile in just the scheduler that I want to use). Yes, at the= >> moment, credit is the only non-experimental scheduler and will likely = be >> the one we choose. However, in the future, when credit2 and possibly >> others are non-experimental, we may choose one of the other schedulers= >> and do not want to carry along credit in our build just because it is >> the primary scheduler. >=20 > I think we need to separate what we want as "upstream", and what > your internal intentions are. Any gap between that would need to be > taken care of by private patches you'd have to carry. >=20 > As "upstream", I think not allowing the default scheduler to be turned > off is quite reasonable an approach. >=20 My immediate reaction to this request is "special casing is bad" and that's what this is straight away. Special cases make the code worse and weaker as a whole. There are no internal intentions here. Our internal intentions are to use the credit scheduler. The intentions are for configurability of all the options and not just some of the options. The goal here is to be more inclusive of various downstreams and the goal of Kconfig being a means by which to support that? The idea here was to encourage more upstream participation and not less. I can hardly see how configurability for an extreme corner case that's very hidden away from the average user would be harmful to upstream. There have been a good deal number of different downstreams that have been encouraging of changes like this but it seems like you are fundamentally opposed. Which is plainly discouraging to people to attempt to engage upstream. At some point it becomes damaging to the Xen upstream where users are unable to get what they need/want out of Xen upstream without having to become their own downstreams and patching. Another example of this can be seen with modern Lenovo laptops that do not properly follow the EFI spec. I've seen numerous patches rejected with the comment of "tell Lenovo to fix their hardware". The result is users of Lenovo hardware walk away feeling that Xen is broken not their hardware. --=20 Doug Goldstein --bGVuVhK4puhNvbkhUmRuEFw4CTEhrXm6S 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 iQJ8BAEBCgBmBQJWk9jyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUR6AP/iikKuQKHSn6bEqbUqDbT+++ vbpSYArG7ct+7BI22CNN6mwcz7rrtxL1by/HQOIZ4Z2HobfKTLeLmxJDlAHcgzl7 7bReedaCUgHnnIN2b6pZA7IJbQ/DSUG4Lc5/okC5LVb01hL6n/BPJB1FgeYbUFZq dhV0YQvzzgDTvIuiEClX5p5Oob8MLKUtxRkqAmWdPDCdZv4fXXAqY6srgiqJeZL/ PewjQ3kl36I1cxISyBHanEk2nXZZIYl59QSCqZW0omB8Vw6hkpUMXHV5XM8NC7VV 7sQlIELu+KG7qKaMtS2LhYgwASZrdMAkmCCi/ooj/V/nIw5tLMeC3QOEZBv3sFTJ JLTnm856fxUh4z4I1jeIBK/S++ywvwGzI08nKbSO4+Lu75xB0saf7ID+3J594Qn7 IPzVKoHfaQnq5DAdtEhpDLaIuZd2qeJJvABJpjUUCnjFciunIgkvG3lVT4Ug8hVu t+hmm2bVP5OeUQ5+mml3iIrZsj/L6VogqypQSH3Y3wXPUpPXTqkwNgSiN1T5ex3d rXsyMJIf3ufMBezngyEoYxvvvuorqt57CayNP46TZnbNGVxcWGMBUNowVlFhokNU IBa8USO+eqAJowjt43j+D33vqujcnfpzJBgtHEc1TDCUl1Z+6XOildk70NSWF6w9 15HVVE5jZ2NPh+zD1nrx =gsMa -----END PGP SIGNATURE----- --bGVuVhK4puhNvbkhUmRuEFw4CTEhrXm6S-- --===============0541463566318464493== 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 --===============0541463566318464493==--