Re: [Xen-devel] [PATCH v3 2/5] build: Hook the schedulers into Kconfig

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.01.16 at 17:58, <cardoe@xxxxxxxxxx> wrote:
> On 1/8/16 10:49 AM, Jan Beulich wrote:
>>>>> On 08.01.16 at 17:30, <jonathan.creekmore@xxxxxxxxx> wrote:
>>> So, based on the Kconfig setup and the linker ASSERT, there should be no
>>> way to have a default scheduler that is not in the build. I wish Kconfig
>>> allowed you to state that you must have at least one option selected or
>>> up to all of the options selected (so I could require 1-4 schedulers
>>> compiled in, but not 0). Unfortunately, the only way that seems allowed
>>> is if you compile code in as modules, which Xen does not (with a choice
>>> block, you can select multiple items as M, but only 1 as Y, but at least
>>> 1 must be present --- since we only support Y, the choice block wouldn't
>>> work for the schedulers).
>> 
>> Perhaps credit should just not be configurable then?
> 
> How much effort are we willing to put in saving someone? We've already
> got these options completely hidden away. We've already given the user a
> warning that what they're doing isn't supported and they shouldn't be
> touching this. Then they have to disable the scheduler that they pick as
> the default. How many people are we expecting to really do this? I'm all
> for idiot proofing things but at some point we've got to say there's
> enough barriers to prevent this from happening. Otherwise we need to put
> a Xen developer in every Xen users home or office.

I personally think that we shouldn't allow .config-s to be produced
that will yield a build failure. No matter whether supported, we'd
expect (as discussed) people to take care of problems themselves,
but we'd also hope for them to contribute back the adjustments
they had to make. I.e. there's need to be a way for someone to
fix the build issue here, and since we're already aware of the issue
I can't see why we should allow in the brokenness. The precautions
are only against issues we didn't happen to notice.

Jan


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