* WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree? [not found] ` <20160906193810.GB22028@kroah.com> @ 2016-09-06 20:21 ` Vineet Gupta 2016-09-06 20:28 ` Vineet Gupta 0 siblings, 1 reply; 6+ messages in thread From: Vineet Gupta @ 2016-09-06 20:21 UTC (permalink / raw) To: linux-snps-arc On 09/06/2016 12:39 PM, gregkh@linuxfoundation.org wrote: > On Tue, Sep 06, 2016@09:50:46AM -0700, Vineet Gupta wrote: >> On 09/05/2016 06:03 AM, gregkh@linuxfoundation.org wrote: >>> The patch below was submitted to be applied to the 4.7-stable tree. >>> >>> I fail to see how this patch meets the stable kernel rules as found at >>> Documentation/stable_kernel_rules.txt. >>> >>> I could be totally wrong, and if so, please respond to >>> <stable at vger.kernel.org> and let me know why this patch should be >>> applied. Otherwise, it is now dropped from my patch queues, never to be >>> seen again. >> Hi Greg, >> >> We are about to switch to new version of GNU tools (gcc 6.x based) which >> unfortunately has a non compatible ABI change - as described in the patch. >> >> Some of our customers are going to stick with older kernels and thus this helps >> them upgrade to newer tools with their existing baseline kernels. > That's nice, but it's a new feature. Stick with old userspace for older > kernels, and use new kernels for new userspace if you so desire. I understand your point. This is what we did at the time of upstreaming the kernel - and was something I was hoping to avoid this time because this is a flag day change. People get locked into kernel version or tools - when the kernel code itself didn't really change a bit. But if this really is against the norms of stable backports, then I suppose we can't do much ? Thx, -Vineet > > We do allow some new gcc fixes to be backported, but that's always where > we have found bugs, or build warnings. Not "we need to support gcc6 for > old kernels", as really, if someone wants to update userspace, they > don't update their kernel? > > thanks, > > greg k-h > ^ permalink raw reply [flat|nested] 6+ messages in thread
* WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree? 2016-09-06 20:21 ` WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree? Vineet Gupta @ 2016-09-06 20:28 ` Vineet Gupta 2016-09-07 6:28 ` Greg Kroah-Hartman 0 siblings, 1 reply; 6+ messages in thread From: Vineet Gupta @ 2016-09-06 20:28 UTC (permalink / raw) To: linux-snps-arc 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. Thx, -Vineet ^ permalink raw reply [flat|nested] 6+ messages in thread
* WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree? 2016-09-06 20:28 ` Vineet Gupta @ 2016-09-07 6:28 ` Greg Kroah-Hartman 2016-09-07 16:38 ` Vineet Gupta 0 siblings, 1 reply; 6+ messages in thread From: Greg Kroah-Hartman @ 2016-09-07 6:28 UTC (permalink / raw) To: linux-snps-arc 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? What prevents them from also updating their kernel? I understand the context, I'm just trying to say that this really is a "new feature" you are wanting here from what I can tell. I'd recommend just having people upgrade their kernel :) thanks, greg k-h ^ permalink raw reply [flat|nested] 6+ messages in thread
* WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree? 2016-09-07 6:28 ` Greg Kroah-Hartman @ 2016-09-07 16:38 ` Vineet Gupta 2016-09-09 11:39 ` Greg Kroah-Hartman 0 siblings, 1 reply; 6+ messages in thread From: Vineet Gupta @ 2016-09-07 16:38 UTC (permalink / raw) To: linux-snps-arc 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.... > I understand the context, I'm just trying to say that this really is a > "new feature" you are wanting here from what I can tell. I'd recommend > just having people upgrade their kernel :) That's what I recommend them too, all the time, but forcing this with a tools upgrade really enforces them and they need to pick a side, before 4.x or after 4.x which is not nice.... Thx, -Vineet > > thanks, > > greg k-h > ^ permalink raw reply [flat|nested] 6+ messages in thread
* WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree? 2016-09-07 16:38 ` Vineet Gupta @ 2016-09-09 11:39 ` Greg Kroah-Hartman 2016-09-09 17:08 ` Vineet Gupta 0 siblings, 1 reply; 6+ messages in thread From: Greg Kroah-Hartman @ 2016-09-09 11:39 UTC (permalink / raw) To: linux-snps-arc 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree? 2016-09-09 11:39 ` Greg Kroah-Hartman @ 2016-09-09 17:08 ` Vineet Gupta 0 siblings, 0 replies; 6+ messages in thread From: Vineet Gupta @ 2016-09-09 17:08 UTC (permalink / raw) To: linux-snps-arc On 09/09/2016 04:39 AM, Greg Kroah-Hartman wrote: > 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? 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-09-09 17:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1473080592214136@kroah.com>
[not found] ` <584a8fcd-6876-de0d-3c5e-8b4dad12c49d@synopsys.com>
[not found] ` <20160906193810.GB22028@kroah.com>
2016-09-06 20:21 ` WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree? Vineet Gupta
2016-09-06 20:28 ` Vineet Gupta
2016-09-07 6:28 ` Greg Kroah-Hartman
2016-09-07 16:38 ` Vineet Gupta
2016-09-09 11:39 ` Greg Kroah-Hartman
2016-09-09 17:08 ` Vineet Gupta
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).