From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 0/4] Allow schedulers to be selectable through Kconfig Date: Thu, 7 Jan 2016 15:00:43 +0000 Message-ID: <1452178843.21055.230.camel@citrix.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aHC3u-00061R-SW for xen-devel@lists.xenproject.org; Thu, 07 Jan 2016 15:01:14 +0000 In-Reply-To: <568E864F02000078000C4731@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 , Doug Goldstein Cc: Ian Jackson , Jonathan Creekmore , Keir Fraser , xen-devel@lists.xenproject.org, Tim Deegan List-Id: xen-devel@lists.xenproject.org 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 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. > > > > 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 that, > > would that be acceptible? That is a proposal that was mentioned on this > > thread before. 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. If we invert the sense then we could call it e.g. CONFIG_STANDARD_PLATFORM and default it to y, I expect it will be easier to discourage people from turning such an option off than to discourage them from turning something like CONFIG_EXPERT on. > 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. While I have reasonably strong opinions about this issue, I do not think they warrant forking Kconfig over. With a suitably strong wording IMHO we have covered ourselves sufficiently. Ian.