WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree?

[Vineet Gupta]

On 09/09/2016 04:39 AM, Greg Kroah-Hartman wrote:
> On Wed, Sep 07, 2016 at 09:38:25AM -0700, Vineet Gupta wrote:
>> On 09/06/2016 11:28 PM, Greg Kroah-Hartman wrote:
>>> On Tue, Sep 06, 2016 at 01:28:45PM -0700, Vineet Gupta wrote:
>>>> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
>>>>>> Not "we need to support gcc6 for
>>>>>> old kernels", as really, if someone wants to update userspace, they
>>>>>> don't update their kernel?
>>>> FWIW, I'm not arguing for the backport inclusion - I'm just trying to explain the
>>>> context more.
>>>>
>>>> Thing is your regular user/customer don't really care/know about these details. So
>>>> there are tools bugs and more often than not the easy answer for tools providers
>>>> is "this is a known issue in gcc x.y which has been fixed in gcc x2.y2 so consider
>>>> upgrading". So it is for such class of users that having such backports makes life
>>>> a little easy.
>>> That's fine, but who would be upgrading their userspace gcc and then
>>> wanting to rebuild their kernel for an old kernel release? 
>> IMHO those are totally unrelated things. user-space gcc/tools upgrade can be
>> forced upon customers by processor vendors (us) saying new tools come with boat
>> load of fixes etc and more often that not it is indeed the case. OTOH, customers
>> typically like to lock into a specific kernel baseline for longish duration
>> because (1) they have out of tree drivers - (2) they have production systems,
>> where they would be iffy to change to a new kernel because prev one is stable etc.
>> I know above seem like made up points and it is easy to dismiss them given that
>> (1)  We don't really work our processes for "enabling" out of tree stuff and (2) a
>> new gcc is more unstable than a new kernel. But that is the mindset when you talk
>> to them.
>>
>>>  What prevents them from also updating their kernel?
>> Their platform baseline and out of tree drivers. Given my experience with
>> maintaining arch port, in the past, an arch rebase has been easier than rebasing
>> the drivers because of the framework improvements, API changes....
> If they have huge patches for their kernels, adding yet-another-one for
> the gcc change should be just fine, right? 

That is true.

>  And you know they aren't
> updating their base stable kernel release number, so even if this was
> added to the stable trees, they wouldn't see it :(

I'd presume they will follow the stable bumps - otherwise it is pointless to ask
for backport in first place.

-Vineet