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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html