Re: [PATCH v4 2/5] build: Hook the schedulers into Kconfig

[Doug Goldstein <cardoe@cardoe.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2727 bytes --]

On 1/11/16 9:43 AM, Jan Beulich wrote:
>>>> On 11.01.16 at 16:10, <jonathan.creekmore@gmail.com> wrote:
>> Jan Beulich writes:
>>>>>> On 08.01.16 at 22:22, <jonathan.creekmore@gmail.com> wrote:
>>>> +config SCHED_CREDIT
>>>> +	bool "Credit scheduler support"
>>>> +	default y
>>>
>>> I continue to think that not making the primary scheduler configurable
>>> would be the better solution to the problems resulting from possibly
>>> all of them getting turned off.
>>
>> Except that is completely contrary to my goal with this patchset (being
>> able to compile in just the scheduler that I want to use). Yes, at the
>> moment, credit is the only non-experimental scheduler and will likely be
>> the one we choose. However, in the future, when credit2 and possibly
>> others are non-experimental, we may choose one of the other schedulers
>> and do not want to carry along credit in our build just because it is
>> the primary scheduler.
> 
> I think we need to separate what we want as "upstream", and what
> your internal intentions are. Any gap between that would need to be
> taken care of by private patches you'd have to carry.
> 
> As "upstream", I think not allowing the default scheduler to be turned
> off is quite reasonable an approach.
> 

My immediate reaction to this request is "special casing is bad" and
that's what this is straight away. Special cases make the code worse and
weaker as a whole.

There are no internal intentions here. Our internal intentions are to
use the credit scheduler. The intentions are for configurability of all
the options and not just some of the options. The goal here is to be
more inclusive of various downstreams and the goal of Kconfig being a
means by which to support that? The idea here was to encourage more
upstream participation and not less. I can hardly see how
configurability for an extreme corner case that's very hidden away from
the average user would be harmful to upstream.

There have been a good deal number of different downstreams that have
been encouraging of changes like this but it seems like you are
fundamentally opposed. Which is plainly discouraging to people to
attempt to engage upstream.

At some point it becomes damaging to the Xen upstream where users are
unable to get what they need/want out of Xen upstream without having to
become their own downstreams and patching. Another example of this can
be seen with modern Lenovo laptops that do not properly follow the EFI
spec. I've seen numerous patches rejected with the comment of "tell
Lenovo to fix their hardware". The result is users of Lenovo hardware
walk away feeling that Xen is broken not their hardware.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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