All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Creekmore <jonathan.creekmore@gmail.com>
To: Doug Goldstein <cardoe@cardoe.com>
Cc: Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Jonathan Creekmore <jonathan.creekmore@gmail.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [PATCH 0/4] Allow schedulers to be selectable through Kconfig
Date: Thu, 07 Jan 2016 09:43:15 -0600	[thread overview]
Message-ID: <m2egdt4cq4.fsf@Nebula.lan> (raw)
In-Reply-To: <568E81DF.5060301@cardoe.com>


Doug Goldstein writes:

> 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, <jonathan.creekmore@gmail.com> 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.
>
> 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.
>
>>
>>> 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.
>>
>
> 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=n make menuconfig && CONFIG_EXPERT=n 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.

So, I have been playing with the environment variable option more and,
by introducing a XEN_CONFIG_EXPERT ?= n variable, normal users will not
see any of the "expert" options (they will be invisible in the
Kconfig). If you enable the environment variable, then the "expert"
options are visible for selection.

Would that be acceptible?

  parent reply	other threads:[~2016-01-07 15:43 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-17 20:59 [PATCH 0/4] Allow schedulers to be selectable through Kconfig Jonathan Creekmore
2015-12-17 20:59 ` [PATCH 1/4] build: Hook the schedulers into Kconfig Jonathan Creekmore
2015-12-18  1:35   ` Dario Faggioli
2015-12-18  2:20     ` Jonathan Creekmore
2015-12-18  9:19       ` Dario Faggioli
2015-12-18 10:52     ` George Dunlap
2015-12-18 11:23       ` Dario Faggioli
2015-12-18  8:57   ` Andrew Cooper
2015-12-18 16:43     ` Jonathan Creekmore
2015-12-17 20:59 ` [PATCH 2/4] build: Alloc space for sched list in the link file Jonathan Creekmore
2015-12-18  9:01   ` Andrew Cooper
2015-12-18 16:40     ` Jonathan Creekmore
2015-12-18 16:48       ` Andrew Cooper
2015-12-18 17:07         ` Jan Beulich
2015-12-18 17:10           ` Andrew Cooper
2015-12-18 17:11           ` Jonathan Creekmore
2015-12-18 17:23             ` Andrew Cooper
2015-12-17 20:59 ` [PATCH 3/4] sched: Register the schedulers into the list Jonathan Creekmore
2015-12-18  1:42   ` Dario Faggioli
2015-12-18  9:03   ` Andrew Cooper
2015-12-17 20:59 ` [PATCH 4/4] sched: Use the auto-generated list of schedulers Jonathan Creekmore
2015-12-18  1:47   ` Dario Faggioli
2015-12-18  9:12   ` Andrew Cooper
2015-12-18 16:44     ` Jonathan Creekmore
2015-12-18 10:50   ` Jan Beulich
2015-12-18 16:00     ` Jonathan Creekmore
2015-12-18 16:43       ` Jan Beulich
2015-12-18 17:24         ` Jonathan Creekmore
2015-12-18 17:30           ` Andrew Cooper
2015-12-18 10:39 ` [PATCH 0/4] Allow schedulers to be selectable through Kconfig Jan Beulich
2015-12-18 10:45 ` Ian Campbell
2015-12-18 10:58   ` Jan Beulich
2015-12-18 11:08   ` Juergen Gross
2015-12-18 11:19     ` Ian Campbell
2015-12-18 11:30     ` Jan Beulich
     [not found]     ` <5673FC6202000078000C122B@suse.com>
2015-12-18 11:41       ` Juergen Gross
2015-12-18 17:56   ` Doug Goldstein
2015-12-18 18:25     ` Andrew Cooper
2016-01-06 14:45     ` Ian Campbell
2016-01-07 14:01       ` Jonathan Creekmore
2016-01-07 14:37         ` Jan Beulich
2016-01-07 15:00           ` Ian Campbell
2016-01-07 15:18             ` Doug Goldstein
2016-01-07 15:31               ` Ian Campbell
2016-01-07 15:43               ` Jonathan Creekmore [this message]
2016-01-07 15:54                 ` Jan Beulich
2016-01-07 15:47               ` Jan Beulich
2016-01-07 15:30             ` Ian Campbell
2016-01-07 15:51               ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2egdt4cq4.fsf@Nebula.lan \
    --to=jonathan.creekmore@gmail.com \
    --cc=JBeulich@suse.com \
    --cc=cardoe@cardoe.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.