Folks,
we have a age old dance of random parties, in particular the embedded
folks, ending up with random ancient kernels on embedded devices. I've
tried to carefully document a few ideas on why and how I believe we
can make automatic kernel backporting scale [0] and part of this will
be to try to bring consensus about a unified front to persuade users,
partners, customers, whatever, to be at least on a kernel listed as
supported on kernel.org. Today we backport down to the last 30
kernels, from 2.6.24 up to 3.14 and while this is manageable right now
I expect the number of supported drivers and features to keep
increasing (I've stopped counting). I am very aware of the reasons to
support a slew of old kernels, but its nothing but our own fault for
not educating enough about the importance on upgrading. I realize this
is an age old issue, but since I think we need scale backports and
wish to remove older kernels from it fast, I wanted to see if any
folks might have ideas on what can help here other than saying, 'if
you use Linux backports, your drivers will be automatically backported
and supported'.
To start off -- what's the *last* kernel you realistically need for
your users to use backports right now? Is it really 2.6.25? Would
anyone kick and scream if for the backports-3.15 release try take
things up to support only down to least 3.0 *right now* ?
[0] http://www.do-not-panic.com/2014/04/automatic-linux-kernel-backporting-with-coccinelle.html
Luis
On 2014-04-09 03:03, Luis R. Rodriguez wrote:
> Folks,
>
> we have a age old dance of random parties, in particular the embedded
> folks, ending up with random ancient kernels on embedded devices. I've
> tried to carefully document a few ideas on why and how I believe we
> can make automatic kernel backporting scale [0] and part of this will
> be to try to bring consensus about a unified front to persuade users,
> partners, customers, whatever, to be at least on a kernel listed as
> supported on kernel.org. Today we backport down to the last 30
> kernels, from 2.6.24 up to 3.14 and while this is manageable right now
> I expect the number of supported drivers and features to keep
> increasing (I've stopped counting). I am very aware of the reasons to
> support a slew of old kernels, but its nothing but our own fault for
> not educating enough about the importance on upgrading. I realize this
> is an age old issue, but since I think we need scale backports and
> wish to remove older kernels from it fast, I wanted to see if any
> folks might have ideas on what can help here other than saying, 'if
> you use Linux backports, your drivers will be automatically backported
> and supported'.
>
> To start off -- what's the *last* kernel you realistically need for
> your users to use backports right now? Is it really 2.6.25? Would
> anyone kick and scream if for the backports-3.15 release try take
> things up to support only down to least 3.0 *right now* ?
>
> [0] http://www.do-not-panic.com/2014/04/automatic-linux-kernel-backporting-with-coccinelle.html
The oldest kernel in OpenWrt that we're still supporting with updates of
the backports tree is 3.3, so raising the minimum requirement to 3.0 is
completely fine with me.
I'm looking forward to getting rid of patches for older kernels that
often get in the way when using various wireless-testing versions ;)
- Felix
On 09/04/14 03:03, Luis R. Rodriguez wrote:
> Folks,
>
[...]
> To start off -- what's the *last* kernel you realistically need for
> your users to use backports right now? Is it really 2.6.25? Would
> anyone kick and scream if for the backports-3.15 release try take
> things up to support only down to least 3.0 *right now* ?
A lot of test teams in broadcom wlan are still using Fedora 15 running a
2.6.38 kernel. We are pushing them to move to Fedora 19.
Regards,
Arend
> [0] http://www.do-not-panic.com/2014/04/automatic-linux-kernel-backporting-with-coccinelle.html
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe backports" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Wed, Apr 9, 2014 at 3:59 AM, Arend van Spriel <[email protected]> wrote:
>
> A lot of test teams in broadcom wlan are still using Fedora 15 running a
> 2.6.38 kernel. We are pushing them to move to Fedora 19.
Fedora 19 seems to be on 3.13, neat!
Luis
On Wed, Apr 9, 2014 at 2:18 AM, Felix Fietkau <[email protected]> wrote:
> The oldest kernel in OpenWrt that we're still supporting with updates of
> the backports tree is 3.3, so raising the minimum requirement to 3.0 is
> completely fine with me.
OK note that 3.3 is not listed on kernel.org as supported. I'm fine in
carrying the stuff for those for now but ultimately it'd also be nice
if we didn't even have to test the kernels in between which are not
listed. This does however raise the question of how often a kernel in
between a list of supported kernels gets picked up to be supported
eventually. Greg, Jiri, do you happen to know what the likelyhood of
that can be?
> I'm looking forward to getting rid of patches for older kernels that
> often get in the way when using various wireless-testing versions ;)
:D
Luis
On Wed, Apr 09, 2014 at 11:28:55AM -0700, Luis R. Rodriguez wrote:
> On Wed, Apr 9, 2014 at 2:18 AM, Felix Fietkau <[email protected]> wrote:
> > The oldest kernel in OpenWrt that we're still supporting with updates of
> > the backports tree is 3.3, so raising the minimum requirement to 3.0 is
> > completely fine with me.
>
> OK note that 3.3 is not listed on kernel.org as supported. I'm fine in
> carrying the stuff for those for now but ultimately it'd also be nice
> if we didn't even have to test the kernels in between which are not
> listed. This does however raise the question of how often a kernel in
> between a list of supported kernels gets picked up to be supported
> eventually. Greg, Jiri, do you happen to know what the likelyhood of
> that can be?
I don't know of anything ever getting picked up after I have said it
would not be supported anymore.
thanks,
greg k-h
On Wed, Apr 9, 2014 at 12:12 PM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Wed, Apr 09, 2014 at 11:28:55AM -0700, Luis R. Rodriguez wrote:
>> On Wed, Apr 9, 2014 at 2:18 AM, Felix Fietkau <[email protected]> wrote:
>> > The oldest kernel in OpenWrt that we're still supporting with updates of
>> > the backports tree is 3.3, so raising the minimum requirement to 3.0 is
>> > completely fine with me.
>>
>> OK note that 3.3 is not listed on kernel.org as supported. I'm fine in
>> carrying the stuff for those for now but ultimately it'd also be nice
>> if we didn't even have to test the kernels in between which are not
>> listed. This does however raise the question of how often a kernel in
>> between a list of supported kernels gets picked up to be supported
>> eventually. Greg, Jiri, do you happen to know what the likelyhood of
>> that can be?
>
> I don't know of anything ever getting picked up after I have said it
> would not be supported anymore.
Great! How soon after a release do you mention whether or not it will
be supported? Like say, 3.14, which was just released. Also, as of
late are you aware any distribution picking an unsupported kernel for
their next choice of kernel?
Luis
On Wed, Apr 09, 2014 at 01:01:23PM -0700, Luis R. Rodriguez wrote:
> On Wed, Apr 9, 2014 at 12:12 PM, Greg Kroah-Hartman
> <[email protected]> wrote:
> > On Wed, Apr 09, 2014 at 11:28:55AM -0700, Luis R. Rodriguez wrote:
> >> On Wed, Apr 9, 2014 at 2:18 AM, Felix Fietkau <[email protected]> wrote:
> >> > The oldest kernel in OpenWrt that we're still supporting with updates of
> >> > the backports tree is 3.3, so raising the minimum requirement to 3.0 is
> >> > completely fine with me.
> >>
> >> OK note that 3.3 is not listed on kernel.org as supported. I'm fine in
> >> carrying the stuff for those for now but ultimately it'd also be nice
> >> if we didn't even have to test the kernels in between which are not
> >> listed. This does however raise the question of how often a kernel in
> >> between a list of supported kernels gets picked up to be supported
> >> eventually. Greg, Jiri, do you happen to know what the likelyhood of
> >> that can be?
> >
> > I don't know of anything ever getting picked up after I have said it
> > would not be supported anymore.
>
> Great! How soon after a release do you mention whether or not it will
> be supported? Like say, 3.14, which was just released.
I only mention it around the time that it would normally go end-of-life.
For example, if 3.13 were to be a release that was going to be "long
term", I would only say something around the normal time I would be no
longer supporting it. Like in 2-3 weeks from now.
So for 3.14, I'll not say anything about that until 3.16-rc1 is out,
give or take a week or two.
> Also, as of late are you aware any distribution picking an unsupported
> kernel for their next choice of kernel?
Sure, lots do, as they don't line up with my release cycles (I only pick
1 long term kernel to maintain each year). Look at the Ubuntu releases
for examples of that. Also openSUSE and Fedora (although Fedora does
rev their kernel pretty regularly) don't usually line up. The
"enterprise" distros are different, but even then, they don't always
line up either (which is why Jiri is maintaining 3.12...)
Hope this helps,
greg k-h
On Wed, Apr 9, 2014 at 1:22 PM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Wed, Apr 09, 2014 at 01:01:23PM -0700, Luis R. Rodriguez wrote:
>> On Wed, Apr 9, 2014 at 12:12 PM, Greg Kroah-Hartman
>> <[email protected]> wrote:
>> > On Wed, Apr 09, 2014 at 11:28:55AM -0700, Luis R. Rodriguez wrote:
>> >> On Wed, Apr 9, 2014 at 2:18 AM, Felix Fietkau <[email protected]> wrote:
>> >> > The oldest kernel in OpenWrt that we're still supporting with updates of
>> >> > the backports tree is 3.3, so raising the minimum requirement to 3.0 is
>> >> > completely fine with me.
>> >>
>> >> OK note that 3.3 is not listed on kernel.org as supported. I'm fine in
>> >> carrying the stuff for those for now but ultimately it'd also be nice
>> >> if we didn't even have to test the kernels in between which are not
>> >> listed. This does however raise the question of how often a kernel in
>> >> between a list of supported kernels gets picked up to be supported
>> >> eventually. Greg, Jiri, do you happen to know what the likelyhood of
>> >> that can be?
>> >
>> > I don't know of anything ever getting picked up after I have said it
>> > would not be supported anymore.
>>
>> Great! How soon after a release do you mention whether or not it will
>> be supported? Like say, 3.14, which was just released.
>
> I only mention it around the time that it would normally go end-of-life.
>
> For example, if 3.13 were to be a release that was going to be "long
> term", I would only say something around the normal time I would be no
> longer supporting it. Like in 2-3 weeks from now.
>
> So for 3.14, I'll not say anything about that until 3.16-rc1 is out,
> give or take a week or two.
>
>> Also, as of late are you aware any distribution picking an unsupported
>> kernel for their next choice of kernel?
>
> Sure, lots do, as they don't line up with my release cycles (I only pick
> 1 long term kernel to maintain each year). Look at the Ubuntu releases
> for examples of that. Also openSUSE and Fedora (although Fedora does
> rev their kernel pretty regularly) don't usually line up. The
> "enterprise" distros are different, but even then, they don't always
> line up either (which is why Jiri is maintaining 3.12...)
>
> Hope this helps,
It does! Unless I don't hear any complaints then given that some
distributions might choose a kernel in between and given also your
great documented story behind the gains on trying to steer folks
together on the 'ol 2.6.32 [0] and this now being faded, I'll be
bumping backports to only support >= 3.0 soon, but we'll include all
the series from 3.0 up to the latest. That should shrink compile /
test time / support time on backports to 1/2.
[0] http://www.kroah.com/log/linux/2.6.32-stable.html
Luis
On Wed, Apr 09, 2014 at 01:52:29PM -0700, Luis R. Rodriguez wrote:
> On Wed, Apr 9, 2014 at 1:22 PM, Greg Kroah-Hartman
> <[email protected]> wrote:
> > On Wed, Apr 09, 2014 at 01:01:23PM -0700, Luis R. Rodriguez wrote:
> >> On Wed, Apr 9, 2014 at 12:12 PM, Greg Kroah-Hartman
> >> <[email protected]> wrote:
> >> > On Wed, Apr 09, 2014 at 11:28:55AM -0700, Luis R. Rodriguez wrote:
> >> >> On Wed, Apr 9, 2014 at 2:18 AM, Felix Fietkau <[email protected]> wrote:
> >> >> > The oldest kernel in OpenWrt that we're still supporting with updates of
> >> >> > the backports tree is 3.3, so raising the minimum requirement to 3.0 is
> >> >> > completely fine with me.
> >> >>
> >> >> OK note that 3.3 is not listed on kernel.org as supported. I'm fine in
> >> >> carrying the stuff for those for now but ultimately it'd also be nice
> >> >> if we didn't even have to test the kernels in between which are not
> >> >> listed. This does however raise the question of how often a kernel in
> >> >> between a list of supported kernels gets picked up to be supported
> >> >> eventually. Greg, Jiri, do you happen to know what the likelyhood of
> >> >> that can be?
> >> >
> >> > I don't know of anything ever getting picked up after I have said it
> >> > would not be supported anymore.
> >>
> >> Great! How soon after a release do you mention whether or not it will
> >> be supported? Like say, 3.14, which was just released.
> >
> > I only mention it around the time that it would normally go end-of-life.
> >
> > For example, if 3.13 were to be a release that was going to be "long
> > term", I would only say something around the normal time I would be no
> > longer supporting it. Like in 2-3 weeks from now.
> >
> > So for 3.14, I'll not say anything about that until 3.16-rc1 is out,
> > give or take a week or two.
> >
> >> Also, as of late are you aware any distribution picking an unsupported
> >> kernel for their next choice of kernel?
> >
> > Sure, lots do, as they don't line up with my release cycles (I only pick
> > 1 long term kernel to maintain each year). Look at the Ubuntu releases
> > for examples of that. Also openSUSE and Fedora (although Fedora does
> > rev their kernel pretty regularly) don't usually line up. The
> > "enterprise" distros are different, but even then, they don't always
> > line up either (which is why Jiri is maintaining 3.12...)
> >
> > Hope this helps,
>
> It does! Unless I don't hear any complaints then given that some
> distributions might choose a kernel in between and given also your
> great documented story behind the gains on trying to steer folks
> together on the 'ol 2.6.32 [0] and this now being faded, I'll be
> bumping backports to only support >= 3.0 soon, but we'll include all
> the series from 3.0 up to the latest. That should shrink compile /
> test time / support time on backports to 1/2.
Why 3.0? That's not supported by anyone anymore for "new hardware", I'd
move to 3.2 if you could, as that's the Debian stable release that will
be maintained for quite some time yet:
https://www.kernel.org/category/releases.html
thanks,
greg k-h
On Wed, 2014-04-09 at 14:06 -0700, Greg Kroah-Hartman wrote:
> Why 3.0? That's not supported by anyone anymore for "new hardware", I'd
> move to 3.2 if you could, as that's the Debian stable release that will
> be maintained for quite some time yet:
> https://www.kernel.org/category/releases.html
We still need 3.0 for an ongoing project.
johannes
At Wed, 9 Apr 2014 14:06:13 -0700,
Greg Kroah-Hartman wrote:
>
> On Wed, Apr 09, 2014 at 01:52:29PM -0700, Luis R. Rodriguez wrote:
> > On Wed, Apr 9, 2014 at 1:22 PM, Greg Kroah-Hartman
> > <[email protected]> wrote:
> > > On Wed, Apr 09, 2014 at 01:01:23PM -0700, Luis R. Rodriguez wrote:
> > >> On Wed, Apr 9, 2014 at 12:12 PM, Greg Kroah-Hartman
> > >> <[email protected]> wrote:
> > >> > On Wed, Apr 09, 2014 at 11:28:55AM -0700, Luis R. Rodriguez wrote:
> > >> >> On Wed, Apr 9, 2014 at 2:18 AM, Felix Fietkau <[email protected]> wrote:
> > >> >> > The oldest kernel in OpenWrt that we're still supporting with updates of
> > >> >> > the backports tree is 3.3, so raising the minimum requirement to 3.0 is
> > >> >> > completely fine with me.
> > >> >>
> > >> >> OK note that 3.3 is not listed on kernel.org as supported. I'm fine in
> > >> >> carrying the stuff for those for now but ultimately it'd also be nice
> > >> >> if we didn't even have to test the kernels in between which are not
> > >> >> listed. This does however raise the question of how often a kernel in
> > >> >> between a list of supported kernels gets picked up to be supported
> > >> >> eventually. Greg, Jiri, do you happen to know what the likelyhood of
> > >> >> that can be?
> > >> >
> > >> > I don't know of anything ever getting picked up after I have said it
> > >> > would not be supported anymore.
> > >>
> > >> Great! How soon after a release do you mention whether or not it will
> > >> be supported? Like say, 3.14, which was just released.
> > >
> > > I only mention it around the time that it would normally go end-of-life.
> > >
> > > For example, if 3.13 were to be a release that was going to be "long
> > > term", I would only say something around the normal time I would be no
> > > longer supporting it. Like in 2-3 weeks from now.
> > >
> > > So for 3.14, I'll not say anything about that until 3.16-rc1 is out,
> > > give or take a week or two.
> > >
> > >> Also, as of late are you aware any distribution picking an unsupported
> > >> kernel for their next choice of kernel?
> > >
> > > Sure, lots do, as they don't line up with my release cycles (I only pick
> > > 1 long term kernel to maintain each year). Look at the Ubuntu releases
> > > for examples of that. Also openSUSE and Fedora (although Fedora does
> > > rev their kernel pretty regularly) don't usually line up. The
> > > "enterprise" distros are different, but even then, they don't always
> > > line up either (which is why Jiri is maintaining 3.12...)
> > >
> > > Hope this helps,
> >
> > It does! Unless I don't hear any complaints then given that some
> > distributions might choose a kernel in between and given also your
> > great documented story behind the gains on trying to steer folks
> > together on the 'ol 2.6.32 [0] and this now being faded, I'll be
> > bumping backports to only support >= 3.0 soon, but we'll include all
> > the series from 3.0 up to the latest. That should shrink compile /
> > test time / support time on backports to 1/2.
>
> Why 3.0? That's not supported by anyone anymore for "new hardware", I'd
> move to 3.2 if you could, as that's the Debian stable release that will
> be maintained for quite some time yet:
> https://www.kernel.org/category/releases.html
Well, the support for "new hardware" is what backports project itself
does, isn't it?
Besides, SLES11 is still supported, so yes, including 3.0.x would be
helpful.
thanks,
Takashi
On Thu, Apr 10, 2014 at 12:44 AM, Takashi Iwai <[email protected]> wrote:
> At Wed, 9 Apr 2014 14:06:13 -0700,
> Greg Kroah-Hartman wrote:
>>
>> On Wed, Apr 09, 2014 at 01:52:29PM -0700, Luis R. Rodriguez wrote:
>> > On Wed, Apr 9, 2014 at 1:22 PM, Greg Kroah-Hartman
>> > <[email protected]> wrote:
>> > > On Wed, Apr 09, 2014 at 01:01:23PM -0700, Luis R. Rodriguez wrote:
>> > >> On Wed, Apr 9, 2014 at 12:12 PM, Greg Kroah-Hartman
>> > >> <[email protected]> wrote:
>> > >> > On Wed, Apr 09, 2014 at 11:28:55AM -0700, Luis R. Rodriguez wrote:
>> > >> >> On Wed, Apr 9, 2014 at 2:18 AM, Felix Fietkau <[email protected]> wrote:
>> > >> >> > The oldest kernel in OpenWrt that we're still supporting with updates of
>> > >> >> > the backports tree is 3.3, so raising the minimum requirement to 3.0 is
>> > >> >> > completely fine with me.
>> > >> >>
>> > >> >> OK note that 3.3 is not listed on kernel.org as supported. I'm fine in
>> > >> >> carrying the stuff for those for now but ultimately it'd also be nice
>> > >> >> if we didn't even have to test the kernels in between which are not
>> > >> >> listed. This does however raise the question of how often a kernel in
>> > >> >> between a list of supported kernels gets picked up to be supported
>> > >> >> eventually. Greg, Jiri, do you happen to know what the likelyhood of
>> > >> >> that can be?
>> > >> >
>> > >> > I don't know of anything ever getting picked up after I have said it
>> > >> > would not be supported anymore.
>> > >>
>> > >> Great! How soon after a release do you mention whether or not it will
>> > >> be supported? Like say, 3.14, which was just released.
>> > >
>> > > I only mention it around the time that it would normally go end-of-life.
>> > >
>> > > For example, if 3.13 were to be a release that was going to be "long
>> > > term", I would only say something around the normal time I would be no
>> > > longer supporting it. Like in 2-3 weeks from now.
>> > >
>> > > So for 3.14, I'll not say anything about that until 3.16-rc1 is out,
>> > > give or take a week or two.
>> > >
>> > >> Also, as of late are you aware any distribution picking an unsupported
>> > >> kernel for their next choice of kernel?
>> > >
>> > > Sure, lots do, as they don't line up with my release cycles (I only pick
>> > > 1 long term kernel to maintain each year). Look at the Ubuntu releases
>> > > for examples of that. Also openSUSE and Fedora (although Fedora does
>> > > rev their kernel pretty regularly) don't usually line up. The
>> > > "enterprise" distros are different, but even then, they don't always
>> > > line up either (which is why Jiri is maintaining 3.12...)
>> > >
>> > > Hope this helps,
>> >
>> > It does! Unless I don't hear any complaints then given that some
>> > distributions might choose a kernel in between and given also your
>> > great documented story behind the gains on trying to steer folks
>> > together on the 'ol 2.6.32 [0] and this now being faded, I'll be
>> > bumping backports to only support >= 3.0 soon, but we'll include all
>> > the series from 3.0 up to the latest. That should shrink compile /
>> > test time / support time on backports to 1/2.
>>
>> Why 3.0? That's not supported by anyone anymore for "new hardware", I'd
>> move to 3.2 if you could, as that's the Debian stable release that will
>> be maintained for quite some time yet:
>> https://www.kernel.org/category/releases.html
>
> Well, the support for "new hardware" is what backports project itself
> does, isn't it?
>
> Besides, SLES11 is still supported, so yes, including 3.0.x would be
> helpful.
That's two stakeholders for 3.0 -- but nothing is voiced for anything
older than that. Today I will rip the older kernels into oblivion.
Thanks for all the feedback!
Luis
On 04/10/14 18:59, Luis R. Rodriguez wrote:
> On Thu, Apr 10, 2014 at 12:44 AM, Takashi Iwai<[email protected]> wrote:
>> At Wed, 9 Apr 2014 14:06:13 -0700,
>> Greg Kroah-Hartman wrote:
>>>
>>> On Wed, Apr 09, 2014 at 01:52:29PM -0700, Luis R. Rodriguez wrote:
>>>> On Wed, Apr 9, 2014 at 1:22 PM, Greg Kroah-Hartman
>>>> <[email protected]> wrote:
>>>>> On Wed, Apr 09, 2014 at 01:01:23PM -0700, Luis R. Rodriguez wrote:
>>>>>> On Wed, Apr 9, 2014 at 12:12 PM, Greg Kroah-Hartman
>>>>>> <[email protected]> wrote:
>>>>>>> On Wed, Apr 09, 2014 at 11:28:55AM -0700, Luis R. Rodriguez wrote:
>>>>>>>> On Wed, Apr 9, 2014 at 2:18 AM, Felix Fietkau<[email protected]> wrote:
>>>>>>>>> The oldest kernel in OpenWrt that we're still supporting with updates of
>>>>>>>>> the backports tree is 3.3, so raising the minimum requirement to 3.0 is
>>>>>>>>> completely fine with me.
>>>>>>>>
>>>>>>>> OK note that 3.3 is not listed on kernel.org as supported. I'm fine in
>>>>>>>> carrying the stuff for those for now but ultimately it'd also be nice
>>>>>>>> if we didn't even have to test the kernels in between which are not
>>>>>>>> listed. This does however raise the question of how often a kernel in
>>>>>>>> between a list of supported kernels gets picked up to be supported
>>>>>>>> eventually. Greg, Jiri, do you happen to know what the likelyhood of
>>>>>>>> that can be?
>>>>>>>
>>>>>>> I don't know of anything ever getting picked up after I have said it
>>>>>>> would not be supported anymore.
>>>>>>
>>>>>> Great! How soon after a release do you mention whether or not it will
>>>>>> be supported? Like say, 3.14, which was just released.
>>>>>
>>>>> I only mention it around the time that it would normally go end-of-life.
>>>>>
>>>>> For example, if 3.13 were to be a release that was going to be "long
>>>>> term", I would only say something around the normal time I would be no
>>>>> longer supporting it. Like in 2-3 weeks from now.
>>>>>
>>>>> So for 3.14, I'll not say anything about that until 3.16-rc1 is out,
>>>>> give or take a week or two.
>>>>>
>>>>>> Also, as of late are you aware any distribution picking an unsupported
>>>>>> kernel for their next choice of kernel?
>>>>>
>>>>> Sure, lots do, as they don't line up with my release cycles (I only pick
>>>>> 1 long term kernel to maintain each year). Look at the Ubuntu releases
>>>>> for examples of that. Also openSUSE and Fedora (although Fedora does
>>>>> rev their kernel pretty regularly) don't usually line up. The
>>>>> "enterprise" distros are different, but even then, they don't always
>>>>> line up either (which is why Jiri is maintaining 3.12...)
>>>>>
>>>>> Hope this helps,
>>>>
>>>> It does! Unless I don't hear any complaints then given that some
>>>> distributions might choose a kernel in between and given also your
>>>> great documented story behind the gains on trying to steer folks
>>>> together on the 'ol 2.6.32 [0] and this now being faded, I'll be
>>>> bumping backports to only support>= 3.0 soon, but we'll include all
>>>> the series from 3.0 up to the latest. That should shrink compile /
>>>> test time / support time on backports to 1/2.
>>>
>>> Why 3.0? That's not supported by anyone anymore for "new hardware", I'd
>>> move to 3.2 if you could, as that's the Debian stable release that will
>>> be maintained for quite some time yet:
>>> https://www.kernel.org/category/releases.html
>>
>> Well, the support for "new hardware" is what backports project itself
>> does, isn't it?
>>
>> Besides, SLES11 is still supported, so yes, including 3.0.x would be
>> helpful.
>
> That's two stakeholders for 3.0 -- but nothing is voiced for anything
> older than that. Today I will rip the older kernels into oblivion.
> Thanks for all the feedback!
Ok, I guess my voice was cracking when I mentioned 2.6.38 as being used
over here. I am probably alone in that desert.
Regards,
Arend
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe backports" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 10, 2014 at 10:04 AM, Arend van Spriel <[email protected]> wrote:
> On 04/10/14 18:59, Luis R. Rodriguez wrote:
>>
>> On Thu, Apr 10, 2014 at 12:44 AM, Takashi Iwai<[email protected]> wrote:
>>>
>>> At Wed, 9 Apr 2014 14:06:13 -0700,
>>> Greg Kroah-Hartman wrote:
>>>>
>>>>
>>>> On Wed, Apr 09, 2014 at 01:52:29PM -0700, Luis R. Rodriguez wrote:
>>>>>
>>>>> On Wed, Apr 9, 2014 at 1:22 PM, Greg Kroah-Hartman
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> On Wed, Apr 09, 2014 at 01:01:23PM -0700, Luis R. Rodriguez wrote:
>>>>>>>
>>>>>>> On Wed, Apr 9, 2014 at 12:12 PM, Greg Kroah-Hartman
>>>>>>> <[email protected]> wrote:
>>>>>>>>
>>>>>>>> On Wed, Apr 09, 2014 at 11:28:55AM -0700, Luis R. Rodriguez wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Apr 9, 2014 at 2:18 AM, Felix Fietkau<[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> The oldest kernel in OpenWrt that we're still supporting with
>>>>>>>>>> updates of
>>>>>>>>>> the backports tree is 3.3, so raising the minimum requirement to
>>>>>>>>>> 3.0 is
>>>>>>>>>> completely fine with me.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> OK note that 3.3 is not listed on kernel.org as supported. I'm fine
>>>>>>>>> in
>>>>>>>>> carrying the stuff for those for now but ultimately it'd also be
>>>>>>>>> nice
>>>>>>>>> if we didn't even have to test the kernels in between which are not
>>>>>>>>> listed. This does however raise the question of how often a kernel
>>>>>>>>> in
>>>>>>>>> between a list of supported kernels gets picked up to be supported
>>>>>>>>> eventually. Greg, Jiri, do you happen to know what the likelyhood
>>>>>>>>> of
>>>>>>>>> that can be?
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't know of anything ever getting picked up after I have said it
>>>>>>>> would not be supported anymore.
>>>>>>>
>>>>>>>
>>>>>>> Great! How soon after a release do you mention whether or not it will
>>>>>>> be supported? Like say, 3.14, which was just released.
>>>>>>
>>>>>>
>>>>>> I only mention it around the time that it would normally go
>>>>>> end-of-life.
>>>>>>
>>>>>> For example, if 3.13 were to be a release that was going to be "long
>>>>>> term", I would only say something around the normal time I would be no
>>>>>> longer supporting it. Like in 2-3 weeks from now.
>>>>>>
>>>>>> So for 3.14, I'll not say anything about that until 3.16-rc1 is out,
>>>>>> give or take a week or two.
>>>>>>
>>>>>>> Also, as of late are you aware any distribution picking an
>>>>>>> unsupported
>>>>>>> kernel for their next choice of kernel?
>>>>>>
>>>>>>
>>>>>> Sure, lots do, as they don't line up with my release cycles (I only
>>>>>> pick
>>>>>> 1 long term kernel to maintain each year). Look at the Ubuntu
>>>>>> releases
>>>>>> for examples of that. Also openSUSE and Fedora (although Fedora does
>>>>>> rev their kernel pretty regularly) don't usually line up. The
>>>>>> "enterprise" distros are different, but even then, they don't always
>>>>>> line up either (which is why Jiri is maintaining 3.12...)
>>>>>>
>>>>>> Hope this helps,
>>>>>
>>>>>
>>>>> It does! Unless I don't hear any complaints then given that some
>>>>> distributions might choose a kernel in between and given also your
>>>>> great documented story behind the gains on trying to steer folks
>>>>> together on the 'ol 2.6.32 [0] and this now being faded, I'll be
>>>>> bumping backports to only support>= 3.0 soon, but we'll include all
>>>>> the series from 3.0 up to the latest. That should shrink compile /
>>>>> test time / support time on backports to 1/2.
>>>>
>>>>
>>>> Why 3.0? That's not supported by anyone anymore for "new hardware", I'd
>>>> move to 3.2 if you could, as that's the Debian stable release that will
>>>> be maintained for quite some time yet:
>>>> https://www.kernel.org/category/releases.html
>>>
>>>
>>> Well, the support for "new hardware" is what backports project itself
>>> does, isn't it?
>>>
>>> Besides, SLES11 is still supported, so yes, including 3.0.x would be
>>> helpful.
>>
>>
>> That's two stakeholders for 3.0 -- but nothing is voiced for anything
>> older than that. Today I will rip the older kernels into oblivion.
>> Thanks for all the feedback!
>
>
> Ok, I guess my voice was cracking when I mentioned 2.6.38 as being used over
> here. I am probably alone in that desert.
That's better than 2.6.25 :) what drivers do you need?
Luis
On Wed, 2014-04-09 at 11:18 +0200, Felix Fietkau wrote:
> I'm looking forward to getting rid of patches for older kernels that
> often get in the way when using various wireless-testing versions ;)
What do you frequently get conflicts on? I haven't seen any for a long
time.
johannes
On 2014-04-10 19:16, Johannes Berg wrote:
> On Wed, 2014-04-09 at 11:18 +0200, Felix Fietkau wrote:
>
>> I'm looking forward to getting rid of patches for older kernels that
>> often get in the way when using various wireless-testing versions ;)
>
> What do you frequently get conflicts on? I haven't seen any for a long
> time.
I don't remember. It was in different areas every time I did an update.
- Felix
On Thu, 2014-04-10 at 19:26 +0200, Felix Fietkau wrote:
> On 2014-04-10 19:16, Johannes Berg wrote:
> > On Wed, 2014-04-09 at 11:18 +0200, Felix Fietkau wrote:
> >
> >> I'm looking forward to getting rid of patches for older kernels that
> >> often get in the way when using various wireless-testing versions ;)
> >
> > What do you frequently get conflicts on? I haven't seen any for a long
> > time.
> I don't remember. It was in different areas every time I did an update.
I had a lot of those, but we've converted so much to spatches now that
it hasn't been a concern in a long time (the netlink nlpid/pid thing was
the one that conflicted most for me, but it's long gone)
johannes
On Thu, Apr 10, 2014 at 10:04 AM, Arend van Spriel <[email protected]> wrote:
> Ok, I guess my voice was cracking when I mentioned 2.6.38 as being used over
> here. I am probably alone in that desert.
I thought broadcom didn't use backports? If they do can you explain
how? Also what drivers do you need enabled for your use case ?
Luis
On 10/04/14 20:56, Luis R. Rodriguez wrote:
> On Thu, Apr 10, 2014 at 10:04 AM, Arend van Spriel <[email protected]> wrote:
>> Ok, I guess my voice was cracking when I mentioned 2.6.38 as being used over
>> here. I am probably alone in that desert.
>
> I thought broadcom didn't use backports? If they do can you explain
> how? Also what drivers do you need enabled for your use case ?
That was 2 years ago when you asked me ;-) Since then I have been using
it to backport the brcm80211 mainline drivers to 1) Android kernel, ie.
3.4 kernel, and 2) Fedora 19 which is actually fixed to 3.11 kernel.
So we use backports these days for enabling brcm80211 drivers on various
test equipment that uses older kernels.
Regards,
Arend
On Fri, Apr 11, 2014 at 12:51 AM, Arend van Spriel <[email protected]> wrote:
> That was 2 years ago when you asked me ;-) Since then I have been using it
> to backport the brcm80211 mainline drivers to 1) Android kernel, ie. 3.4
> kernel, and 2) Fedora 19 which is actually fixed to 3.11 kernel.
>
> So we use backports these days for enabling brcm80211 drivers on various
> test equipment that uses older kernels.
Neat! All the kernels seem covered, what stuff was using the older
stuff and can those not be moved to newer kernels ?
Luis