[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.