Bumping required kernels to 3.0 for Linux backports ?

Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Felix Fietkau]

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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

On Wed, Apr 9, 2014 at 2:18 AM, Felix Fietkau <nbd@openwrt.org> 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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Greg Kroah-Hartman]

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 <nbd@openwrt.org> 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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

On Wed, Apr 9, 2014 at 12:12 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> 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 <nbd@openwrt.org> 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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Greg Kroah-Hartman]

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
> <gregkh@linuxfoundation.org> 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 <nbd@openwrt.org> 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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

On Wed, Apr 9, 2014 at 1:22 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> 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
>> <gregkh@linuxfoundation.org> 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 <nbd@openwrt.org> 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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Greg Kroah-Hartman]

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
> <gregkh@linuxfoundation.org> 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
> >> <gregkh@linuxfoundation.org> 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 <nbd@openwrt.org> 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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Johannes Berg]

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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Takashi Iwai]

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
> > <gregkh@linuxfoundation.org> 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
> > >> <gregkh@linuxfoundation.org> 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 <nbd@openwrt.org> 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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

On Thu, Apr 10, 2014 at 12:44 AM, Takashi Iwai <tiwai@suse.de> 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
>> > <gregkh@linuxfoundation.org> 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
>> > >> <gregkh@linuxfoundation.org> 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 <nbd@openwrt.org> 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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Arend van Spriel]

On 04/10/14 18:59, Luis R. Rodriguez wrote:
> On Thu, Apr 10, 2014 at 12:44 AM, Takashi Iwai<tiwai@suse.de>  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
>>>> <gregkh@linuxfoundation.org>  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
>>>>>> <gregkh@linuxfoundation.org>  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<nbd@openwrt.org>  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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

On Thu, Apr 10, 2014 at 10:04 AM, Arend van Spriel <arend@broadcom.com> wrote:
> On 04/10/14 18:59, Luis R. Rodriguez wrote:
>>
>> On Thu, Apr 10, 2014 at 12:44 AM, Takashi Iwai<tiwai@suse.de>  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
>>>>> <gregkh@linuxfoundation.org>  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
>>>>>>> <gregkh@linuxfoundation.org>  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<nbd@openwrt.org>
>>>>>>>>> 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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Loren Kirkby]

[-- Attachment #1: Type: text/plain, Size: 4415 bytes --]

On Apr 10, 2014, at 10:04 AM, Arend van Spriel <arend@broadcom.com> wrote:

> On 04/10/14 18:59, Luis R. Rodriguez wrote:
>> On Thu, Apr 10, 2014 at 12:44 AM, Takashi Iwai<tiwai@suse.de>  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
>>>>> <gregkh@linuxfoundation.org>  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
>>>>>>> <gregkh@linuxfoundation.org>  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<nbd@openwrt.org>  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

You’re not alone.  :)  We use 2.6.38 over here at Dropcam and use backports for the Bluetooth subsystem (and HCI UART driver).  

Many thanks to everybody involved — b	ackports is a really amazing project.

Cheers,
Loren Kirkby
Dropcam


[-- Attachment #2: Type: text/html, Size: 5590 bytes --]

Re: Bumping required kernels to 3.0 for Linux backports ?

[Loren Kirkby]

On Apr 10, 2014, at 10:04 AM, Arend van Spriel <arend@broadcom.com> wrote:

> On 04/10/14 18:59, Luis R. Rodriguez wrote:
>> On Thu, Apr 10, 2014 at 12:44 AM, Takashi Iwai<tiwai@suse.de>  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
>>>>> <gregkh@linuxfoundation.org>  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
>>>>>>> <gregkh@linuxfoundation.org>  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<nbd@openwrt.org>  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

You’re not alone.  :)  We use 2.6.38 over here at Dropcam and use backports for the Bluetooth subsystem (and HCI UART driver).  

Many thanks to everybody involved — b	ackports is a really amazing project.

Cheers,
Loren Kirkby
Dropcam

Re: Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

On Thu, Apr 10, 2014 at 10:04 AM, Arend van Spriel <arend@broadcom.com> 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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Arend van Spriel]

On 10/04/14 20:56, Luis R. Rodriguez wrote:
> On Thu, Apr 10, 2014 at 10:04 AM, Arend van Spriel <arend@broadcom.com> 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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

On Fri, Apr 11, 2014 at 12:51 AM, Arend van Spriel <arend@broadcom.com> 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

RE: Bumping required kernels to 3.0 for Linux backports ?

[Harrison Lee]

Compat-wireless drivers have been very useful to users like us, who have to work with embedded linux system based on old kernel. For example, we work on a arm based system with 2.6.28 kernel, and could use ath9k drivers thanks to compat-wireless-3.6.8-1. The company who provided the SDK, a big name company, does not have any plan to upgrade the kernel, so we are stuck with it due to all the customized drivers for the chip.

But the situation seems to be changing. Compat-drivers does not support 2.6.28 any more for ath9k. It only supports from 2.6.30 according to "dependencies" list.

I've just joined the mailing list to learn how to backport wwan drivers. And the first message I see is about dumping supports for older kernels...

Would there be any alternatives for old kernel users, then?

Harrison

> 
> 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
 

__________ Information from ESET NOD32 Antivirus, version of virus signature database 9666 (20140411) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

Re: Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

On Fri, Apr 11, 2014 at 7:22 AM, Harrison Lee <harrisonl@tme-inc.com> wrote=
:
> Compat-wireless drivers have been very useful to users like us, who have =
to work with embedded linux system based on old kernel. For example, we wor=
k on a arm based system with 2.6.28 kernel, and could use ath9k drivers tha=
nks to compat-wireless-3.6.8-1. The company who provided the SDK, a big nam=
e company, does not have any plan to upgrade the kernel, so we are stuck wi=
th it due to all the customized drivers for the chip.

compat-wireless is ancient and anyone giving you anything like a
release like that is not giving you the best, which is the latest, and
that is anything based on the latest kernel releases, right now, v3.14
based which I hope today to make a release.

> But the situation seems to be changing. Compat-drivers does not support 2=
.6.28 any more for ath9k. It only supports from 2.6.30 according to "depend=
encies" list.

compat-drivers is ancient as well, the new project is backports and we
will be deprecating older kernels to help us scale better.

> I've just joined the mailing list to learn how to backport wwan drivers. =
And the first message I see is about dumping supports for older kernels...

wwan drivers backports are welcomed, but backporting it to ancient
kenrels, anything below 3.0 is not something I wish to take on now
given the overhead and as I noted the objectives to scale.

> Would there be any alternatives for old kernel users, then?

You could upkeep the maintenance yourself on a separate tree.

  Luis

Re: Bumping required kernels to 3.0 for Linux backports ?

[Johannes Berg]

On Fri, 2014-04-11 at 11:23 -0700, Luis R. Rodriguez wrote:

> compat-drivers is ancient as well, the new project is backports and we
> will be deprecating older kernels to help us scale better.

I know I pushed for the 2.6.24 deprecation, but do you see any
particular issue with other kernels < 3.0? The 2.6.24 was big and ugly,
but none of the other ones seem particularly big/ugly, and there aren't
a ton of patches either ...

Now, I'm all for dropping support if it really makes a difference, and
we might want to drop them from the ckmake tests to reduce the pain, but
I'm not entirely sure we should wholesale remove things if there are
still users for them out there.

johannes

Re: Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

On Fri, Apr 11, 2014 at 11:45 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Fri, 2014-04-11 at 11:23 -0700, Luis R. Rodriguez wrote:
>
>> compat-drivers is ancient as well, the new project is backports and we
>> will be deprecating older kernels to help us scale better.
>
> I know I pushed for the 2.6.24 deprecation, but do you see any
> particular issue with other kernels < 3.0? The 2.6.24 was big and ugly,
> but none of the other ones seem particularly big/ugly, and there aren't
> a ton of patches either ...

On my current not published commit in which I've axed out all older
kernels its allowed me to rip out all the patches which were not split
up atomically and reshuffle and order every single series we have into
the new 4-digit form which implies they are atomically well split.
This can enable us to push for clean architecture on patches moving
forward.

> Now, I'm all for dropping support if it really makes a difference, and
> we might want to drop them from the ckmake tests to reduce the pain, but
> I'm not entirely sure we should wholesale remove things if there are
> still users for them out there.

I think this makes sense if we had an easy way to break things out as
optional right now but we don't, and given that some older patches
weren't really atomic (consider bluetooth for pre 3.0) it would mean
carrying around a pile of mess as optional but to what end if we're
never applying it? What type of review can we expect from these
patches if they are really not maintained? Let's also consider now the
gains of being able to help persuade folks to upgrade if we also
embrace a sensible policy for what kernels we support. One of my goals
is to grow backports with more drivers and new options (in-kernel
support) but if backports can also be used as a carrot to help with
moving the ecosystem forward, I think its a strong element to
consider. So there are two gains here: helping us clean up things, and
setting up a sensible policy that aligns with kernel.org releases /
maintenance cycles.

  Luis

RE: Bumping required kernels to 3.0 for Linux backports ?

[Harrison Lee]

I do understand that dumping "ancient" kernel support would make things a lot easier.
But, in the embedded system world, upgrading kernel isn't that easy like in PC world.
Most of those systems put to market today has 2.6 kernels, and backports project is a great job and it will revive so many systems if it keeps the tradition to support down 2.6.24 as its predecessor.

Best regards,

Harrison

> On Fri, Apr 11, 2014 at 11:45 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Fri, 2014-04-11 at 11:23 -0700, Luis R. Rodriguez wrote:
> >
> >> compat-drivers is ancient as well, the new project is backports and
> we
> >> will be deprecating older kernels to help us scale better.
> >
> > I know I pushed for the 2.6.24 deprecation, but do you see any
> > particular issue with other kernels < 3.0? The 2.6.24 was big and
> ugly,
> > but none of the other ones seem particularly big/ugly, and there
> aren't
> > a ton of patches either ...
> 
> On my current not published commit in which I've axed out all older
> kernels its allowed me to rip out all the patches which were not split
> up atomically and reshuffle and order every single series we have into
> the new 4-digit form which implies they are atomically well split.
> This can enable us to push for clean architecture on patches moving
> forward.
> 
> > Now, I'm all for dropping support if it really makes a difference,
> and
> > we might want to drop them from the ckmake tests to reduce the pain,
> but
> > I'm not entirely sure we should wholesale remove things if there are
> > still users for them out there.
> 
> I think this makes sense if we had an easy way to break things out as
> optional right now but we don't, and given that some older patches
> weren't really atomic (consider bluetooth for pre 3.0) it would mean
> carrying around a pile of mess as optional but to what end if we're
> never applying it? What type of review can we expect from these
> patches if they are really not maintained? Let's also consider now the
> gains of being able to help persuade folks to upgrade if we also
> embrace a sensible policy for what kernels we support. One of my goals
> is to grow backports with more drivers and new options (in-kernel
> support) but if backports can also be used as a carrot to help with
> moving the ecosystem forward, I think its a strong element to
> consider. So there are two gains here: helping us clean up things, and
> setting up a sensible policy that aligns with kernel.org releases /
> maintenance cycles.
> 
>   Luis
> 
 

__________ Information from ESET NOD32 Antivirus, version of virus signature database 9667 (20140411) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

Re: Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

On Fri, Apr 11, 2014 at 12:51 PM, Harrison Lee <harrisonl@tme-inc.com> wrote:
> I do understand that dumping "ancient" kernel support would make things a lot easier.
> But, in the embedded system world, upgrading kernel isn't that easy like in PC world.
> Most of those systems put to market today has 2.6 kernels, and backports project is a great job and it will revive so many systems if it keeps the tradition to support down 2.6.24 as its predecessor.

Supporting bad ways to do embedded development is not a good thing,
which is why I had poked OpenWrt folks, which do *good* embedded
development, and wanted to ensure we support them. Models not
embracing a path to upgrade should seriously consider their
architecture.

  Luis

Re: Bumping required kernels to 3.0 for Linux backports ?

[Johannes Berg]

On Fri, 2014-04-11 at 12:18 -0700, Luis R. Rodriguez wrote:

> On my current not published commit in which I've axed out all older
> kernels its allowed me to rip out all the patches which were not split
> up atomically and reshuffle and order every single series we have into
> the new 4-digit form which implies they are atomically well split.
> This can enable us to push for clean architecture on patches moving
> forward.

I don't think the 4-digit vs. 2/3 digit thing was ever really an
indicator, but I do see that there are a whole bunch of patches,
particularly for Atheros ethernet drivers (!!) for old kernels.

Maybe a better compromise would be to bump those up with the
dependencies file and keep the compat/compat-*.c code around for others,
i.e. selectively reduce just the patches by bumping single driver
dependencies?

> I think this makes sense if we had an easy way to break things out as
> optional right now but we don't, and given that some older patches
> weren't really atomic (consider bluetooth for pre 3.0) 

I haven't looked at Bluetooth, but I wasn't really suggesting that we
make the patches optional - that's never going to work.

Again, like I said above, what we could potentially do is look through
the pain areas (aka big patches) and reduce those by bumping single
drivers/subsystems up in kernel version, instead of a wholesale bump.

As far as 802.11 wireless is concerned, for example, I think the patches
are actually relatively small for the older kernels.

> Let's also consider now the
> gains of being able to help persuade folks to upgrade if we also
> embrace a sensible policy for what kernels we support. One of my goals
> is to grow backports with more drivers and new options (in-kernel
> support) but if backports can also be used as a carrot to help with
> moving the ecosystem forward, I think its a strong element to
> consider. So there are two gains here: helping us clean up things, and
> setting up a sensible policy that aligns with kernel.org releases /
> maintenance cycles.

I'm not a big fan of politicising technical projects. We're mostly all
here to get problems solved, and most of us push for better solutions,
but usually what happens when we try to enforce better solutions
technically is that we just get to maintain the workarounds outside the
community, which makes it more effort for everybody...

johannes

Re: Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

On Fri, Apr 11, 2014 at 1:07 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Fri, 2014-04-11 at 12:18 -0700, Luis R. Rodriguez wrote:
>
>> On my current not published commit in which I've axed out all older
>> kernels its allowed me to rip out all the patches which were not split
>> up atomically and reshuffle and order every single series we have into
>> the new 4-digit form which implies they are atomically well split.
>> This can enable us to push for clean architecture on patches moving
>> forward.
>
> I don't think the 4-digit vs. 2/3 digit thing was ever really an
> indicator, but I do see that there are a whole bunch of patches,
> particularly for Atheros ethernet drivers (!!) for old kernels.

This wasn't ever really well documented, with time I realized that the
more atomic patches were split out the easier it was to review and
understand why a change was made as well as making it easier to learn
how to backport a subsystem driver, but *also* in the end this effort
makes it easier to review if you could end up transformation a series
into SmPL form. In my trimming commits for old kernels I have been
able to split *every* patch into a proper atomic series (with one
exception but I'd document why and ensure we address that one).

> Maybe a better compromise would be to bump those up with the
> dependencies file and keep the compat/compat-*.c code around for others,
> i.e. selectively reduce just the patches by bumping single driver
> dependencies?

That can work too, but that raises the question of what drivers or
subsystems to bump too. Would we just bump everything now to 3.0 ?

>> I think this makes sense if we had an easy way to break things out as
>> optional right now but we don't, and given that some older patches
>> weren't really atomic (consider bluetooth for pre 3.0)
>
> I haven't looked at Bluetooth, but I wasn't really suggesting that we
> make the patches optional - that's never going to work.
>
> Again, like I said above, what we could potentially do is look through
> the pain areas (aka big patches) and reduce those by bumping single
> drivers/subsystems up in kernel version, instead of a wholesale bump.

OK so we'd still be deleting selective patch series? But we'd keep all
the backport module files and header files around, but for what? That
would leave header files lengthy and full of complexity. Would we have
a subsection on documentation that helps folks feel free to use the
framework to go and backport some random driver -if-they-so-wish-
outside of the tree and show how? Is that the idea?

> As far as 802.11 wireless is concerned, for example, I think the patches
> are actually relatively small for the older kernels.

Sure, but again, are we going to bump all 802.11 drivers to say 3.0,
and if so we are going to then just remove all these patches? If not
that implies someone is going to upkeep those patches, and as I
mentioned I think we need to scale better. I want to do less work, not
more.

>> Let's also consider now the
>> gains of being able to help persuade folks to upgrade if we also
>> embrace a sensible policy for what kernels we support. One of my goals
>> is to grow backports with more drivers and new options (in-kernel
>> support) but if backports can also be used as a carrot to help with
>> moving the ecosystem forward, I think its a strong element to
>> consider. So there are two gains here: helping us clean up things, and
>> setting up a sensible policy that aligns with kernel.org releases /
>> maintenance cycles.
>
> I'm not a big fan of politicising technical projects. We're mostly all
> here to get problems solved, and most of us push for better solutions,
> but usually what happens when we try to enforce better solutions
> technically is that we just get to maintain the workarounds outside the
> community, which makes it more effort for everybody...

There's a good-practices gain from bumping kernels to match the
support structure on kernel.org but let me make it clear its not the
primary reason, that'd be a side effect. Ultimately this comes down to
*support* on backports for older kernels, and I just don't want to do
that anymore, we only have so many contributors to backports but many
users, we have to be picky about how we spend our time. I also have
technical reasons to believe that if we want to backports to grow we
need to make it scale and not dropping kernels more often won't scale.
Dropping supported kernels has to become part of our best technical
practices on backports. We can't make everyone happy.

  Luis

Re: Bumping required kernels to 3.0 for Linux backports ?

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

On Fri, Apr 11, 2014 at 08:45:08PM +0200, Johannes Berg wrote:
> Now, I'm all for dropping support if it really makes a difference, and
> we might want to drop them from the ckmake tests to reduce the pain, but
> I'm not entirely sure we should wholesale remove things if there are
> still users for them out there.

Speaking as an end-user of compat-wireless, compat-drivers, and later 
backports, I used them because I was stuck using a nominally-outdated, 
heavily-patched vendor-supplied kernel for an SoC/board that wasn't 
[well] supported by the mainline kernel.

To make things worse, I was trying to get a driver for the cw1200 family 
mainlined.  It finally made it into 3.11, but at the time, the bills 
were being paid by supporting clients that were stuck on 2.6.28, 2.6.35 
and 3.0, which coincidentally were what I was using to develop/test the 
driver at the time of the 3.11 release.

I no longer have any skin in the game (I've moved on to mostly 
microcontroller work) but please, don't drop support for older kernels
if the only reason is to save release-time checks, or worse, "just 
because"

My $0.02,

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org
Delray Beach, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.

[-- Attachment #2: Type: application/pgp-signature, Size: 155 bytes --]

Re: Bumping required kernels to 3.0 for Linux backports ?

[Johannes Berg]

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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Felix Fietkau]

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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Johannes Berg]

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

Re: Bumping required kernels to 3.0 for Linux backports ?

[Arend van Spriel]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Bumping required kernels to 3.0 for Linux backports ?

[Luis R. Rodriguez]

On Wed, Apr 9, 2014 at 3:59 AM, Arend van Spriel <arend@broadcom.com> 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