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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.01.16 at 17:31, <cardoe@xxxxxxxxxx> wrote:
> 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.

I could see such a reaction as being valid if I objected to any of
the configurability changes, but I have a hard time following when
I just ask for the default scheduler to not become configurable.
Plus I'm not the only one involved in getting to a decision here, i.e.
I can easily be overruled by other maintainers.

> 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.

Well, if you followed the discussion closely you may have noticed
we already kind of agreed that using DMI based quirks would be
an acceptable mechanism to help the situation. As to my objection
to make Xen violate the EFI spec by default, I continue to think
this would be a bad idea, and I don't recall any substantial
comments from you proving this a bad position.

And yes, I'm having difficulty accepting massive amounts of
workarounds for various vendors' quirks (be it EFI related or
other), but commonly I accept such if they can be proven to not
negatively impact other systems / platforms. And yes, I sincerely
believe that hardware vendors should do a better job in
implementing their firmware, the more that they managed to
screw up many things in the PC BIOS days already, and one
would think (hope) they would learn from older mistakes. Since
they don't, getting people to put some pressure on them is,
I think, quite appropriate. Working out or accepting side effect
free workarounds in parallel is of course not excluded.

Jan


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