Re: [Xen-devel] [PATCH 0/4] Allow schedulers to be selectable through Kconfig

[Jonathan Creekmore <jonathan.creekmore@xxxxxxxxx>]

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@xxxxxxxxx> 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?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel