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

[gregkh@linuxfoundation.org (Greg Kroah-Hartman)]

On Wed, Sep 07, 2016@09:38:25AM -0700, Vineet Gupta wrote:
> On 09/06/2016 11:28 PM, Greg Kroah-Hartman wrote:
> > On Tue, Sep 06, 2016@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?  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 :(

Unless ARC customers are better than others?

thanks,

greg k-h