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: Thu, 7 Jan 2016 09:18:55 -0600 Message-ID: <568E81DF.5060301@cardoe.com> References: <1450385974-12732-1-git-send-email-jonathan.creekmore@gmail.com> <1450435531.4053.196.camel@citrix.com> <567448E9.2030702@cardoe.com> <1452091541.21055.58.camel@citrix.com> <568E864F02000078000C4731@prv-mh.provo.novell.com> <1452178843.21055.230.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6185484237379999138==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aHCLD-0006tJ-UX for xen-devel@lists.xenproject.org; Thu, 07 Jan 2016 15:19:08 +0000 Received: by mail-qk0-f182.google.com with SMTP id q19so126791117qke.3 for ; Thu, 07 Jan 2016 07:19:02 -0800 (PST) In-Reply-To: <1452178843.21055.230.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 , Jan Beulich Cc: Ian Jackson , Jonathan Creekmore , Keir Fraser , xen-devel@lists.xenproject.org, Tim Deegan List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============6185484237379999138== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vchPaW3uEcXCnI4tEa7VHmbrDGQP3bJRq" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vchPaW3uEcXCnI4tEa7VHmbrDGQP3bJRq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/7/16 9:00 AM, Ian Campbell wrote: > On Thu, 2016-01-07 at 07:37 -0700, Jan Beulich wrote: >>>>> On 07.01.16 at 15:01, wrote: >> >>> Ian Campbell writes: >>> >>>> 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 f= or >>>> 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 su= ch as >>>> yourselves to configure things and I applaud you for doing this in a= n >>>> upstream way (it is the right thing to do). >>>> >>>> My concern is that while you rightly consider yourselves expert enou= gh and >>>> are building something for a specific (and AIUI targeted) use case m= any >>>> normal users tend to think that if they are expert enough to find an= d 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 option= s >>>> because there will be a strong gravity towards them doing so. >>> >>> So, if I add a patch in a v3 of this series that introduces a >>> CONFIG_EXPERT option and hides all of the scheduler options behind th= at, >>> would that be acceptible? That is a proposal that was mentioned on th= is >>> thread before. >=20 > Thinking about it I think I'd avoid the specific name CONFIG_EXPERT due= to > the expectations which Linux's use of the name has set. >=20 > If we invert the sense then we could call it e.g. CONFIG_STANDARD_PLATF= ORM > and default it to y, I expect it will be easier to discourage people fr= om > turning such an option off than to discourage them from turning somethi= ng > like CONFIG_EXPERT on. So I actually like this approach. Maybe tweak the name slightly to CONFIG_SUPPORTED_XEN? It can force settings a certain way and can also make menus invisible. But I'm hoping we can get Jan's buy in here before we post any patchset. >=20 >> With me asking for that option to not have a visible prompt by default= , >> but nevertheless being settable. I do realize that this may not be >> possible with the current kconfig tool, but that's imo the only way to= >> keep people from playing with expert options just because they see >> there's a prompt. No textual warning will help this, I'm afraid. >=20 > While I have reasonably strong opinions about this issue, I do not thin= k > they warrant forking Kconfig over. >=20 > With a suitably strong wording IMHO we have covered ourselves sufficien= tly. >=20 > Ian. >=20 So Jonathan and I have been messing with the hidden option behind a non-menu option (e.g. environment variable). The only way we can get it to work is to require the environment variable to be passed at configuration time and at build time and I doubt you'd want the steps to be "CONFIG_EXPERT=3Dn make menuconfig && CONFIG_EXPERT=3Dn make" to build= Xen. We'll play with this some more if that's desired but given Ian's response I don't know if it is. --=20 Doug Goldstein --vchPaW3uEcXCnI4tEa7VHmbrDGQP3bJRq 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 iQJ8BAEBCgBmBQJWjoHiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUXOMQAJaeuF21hslaBGUlMkSLP5Z3 ZVPrlQEYnsLlrMnW/6fcqRhxcKeVWex3BXxrGBLBhRqfg75jhqpcBAiJUjcLyUUI 4FvZgRbv4m321ecIi6Z2yL6JBq0JhXz3ICY60YkRq/81QCZuIHgzo8cc3c7lfPHk paGKPMLAaudo37slic3N24HX8hnNv2Wze7RWNpSpATxI6ruP1sygbkmHmglP58IV TEY4t+uGW0PQMfvJ3KZBPR5YYpx0Mrp8Fym0nizf6+FS8a4v6A5ooimGNVoSiZgN 1Cy/HyEU/PLXckCFqUgD7Bf4lZLuU/FuW5dQQbnLznLmxewyHwMMvlaa6cgZtsFQ pcpWBiZnL1kRLnn5FsAK4GNC7tyPOp1ODdQjEyLfXNGME8x7TLQJ2R7uCbApTnoK QsBKhOSqWocrBqbmMPofz76pASQKAvh5VJLRv9zWpeB6EF7S1/Wlb8KQx7XFYsjd M21kE5EJRHnwbg8jJJBehT90Ccro2hGwdIG3tapkZLunz8wprCe9k1QDuCCdt0QA t/pbCwbxiMsI9J8Zzw/8Oymqb6ndKG00fbUuDZuHl+1D5qWpXxvWaYlNWpQD+RYB 2WsnbMDY31nE8i4pXk3GBaULwBHOUJgYmvgQG2ojed3ixjZDu1xIEEvZLB5QeMBU 3XYl/RfE8snUtsnqHrqM =JAV6 -----END PGP SIGNATURE----- --vchPaW3uEcXCnI4tEa7VHmbrDGQP3bJRq-- --===============6185484237379999138== 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 --===============6185484237379999138==--