Reaching out to Greg KH for 6 year LTS kernel versions

Florian Fainelli f.fainelli at gmail.com
Fri Aug 12 14:12:30 PDT 2022


On 8/12/22 13:28, Robert Marko wrote:
> On Fri, 12 Aug 2022 at 21:45, Florian Fainelli <f.fainelli at gmail.com> wrote:
>>
>> On 8/12/22 11:09, Robert Marko wrote:
>>> On Fri, 12 Aug 2022 at 19:54, Florian Fainelli <f.fainelli at gmail.com> wrote:
>>>>
>>>> On 8/10/22 13:32, Robert Marko wrote:
>>>>> On Wed, 10 Aug 2022 at 22:30, Philip Prindeville
>>>>> <philipp at redfish-solutions.com> wrote:
>>>>>>
>>>>>> Not to play the devil's advocate but... do we want old kernels hanging out that long?
>>>>>>
>>>>>> Besides not encouraging people to update to new releases that mitigate discovered CVE's, we'd also not pick up David Taht's excellent improvements in Buffer Bloat.
>>>>>
>>>>> I have to agree with this.
>>>>> What would be the benefit for OpenWrt with having LTS kernels
>>>>> supported for 6 years?
>>>>
>>>> One aspect I could see is take for instance a device that is widely
>>>> popular amongst our user base as was TI's ar7 for instance a while back,
>>>> and for which we might have done a Linux 5.4, or 5.10 version at the
>>>> time but we do not wish to continue to maintain.
>>>
>>> I dont see how this is related to LTS kernel support.
>>
>> OK maybe I need to spell out my example more clearly. Let us say that we
>> have a release in 2019 of OpenWrt that supported TI AR7 based upon the
>> Linux 5.4 kernel.
>>
>> Fast forward to 2022, we decide to abandon TI AR7 in master and we stop
>> supporting it entirely for future releases. A very bad Linux security
>> problem show up, and because we care about our users, we keep updating
>> the LTS kernel that was used in the 2019.x release up until, say the
>> said kernel stops being supported. If that support time frame was 6
>> years, then we would really be helping our users.
>>
>> Maybe the wider discussion to be had, is:
>>
>> - when and how do we decide to deprecate a given Linux port, I assume it
>> is when no more users show up or maybe more realistically when OpenWrt
>> developers just cannot keep up with updating those devices because they
>> no longer use those themselves
>>
>> - how long do we want to keep supporting past OpenWrt releases with
>> kernel updates, 2 years, 3/4 years, 6 years to match the kernel
>> lifecycle they are based upon?
> 
> As an idea, I understand this, it would basically be an "LTS" OpenWrt
> release that
> would receive security-only updates.
> 
> However, we had a long discussion on the IRC today and the resources are spread
> rather thin even currently with 2 or 3 releases being supported.
> 
> If its gonna be a volunteer kind of no guarantees release, then maybe
> but I dont see
> how we can manage that as well.

That is fair, if we are spread too thin, and clearly we are, then yes, I 
agree we should focus on the latest releases and people who cannot 
update for whatever reason, be it now unsupported hardware, or high 
availability or whatever should find out a solution. It's open source 
after all :)


>>
>>
>>>
>>>>
>>>> Being able to continue to deliver stable kernel updates in a stable
>>>> OpenWrt branch could be a good way for users to pick up their next xDSL
>>>> router since there are not so many out there that can actually run
>>>> OpenWrt compared to pure Wired/Wi-Fi for instance.
>>>
>>> I can agree with this.
>>>
>>>>
>>>>> Backporting stuff is already hard with only 2 LTS versions supported in OpenWrt.
>>>>
>>>> That argument I am sympathetic with, and the sheer amount of out of tree
>>>> patches we have in OpenWrt is not helping, in fact it definitively makes
>>>> it harder to regularly test, but still somehow we managed to do it.
>>>>
>>>> Since we will merge stable updates eventually, the point would be that
>>>> instead of testing those that are already released, we could try to test
>>>> the release candidates and report back anything we find?
>>>
>>> This is a good idea, not sure how we can do it within OpenWrt though with
>>> the amount of patches we have that make it a pain to bump kernels.
>>
>> Maybe we should give it a spin and see how painful that actually is and
>> then if we can sustain doing that over time it just becomes a thing a
>> group of volunteers can do?
>>
>> After all, we do go through that exercise fairly frequently.
> 
> This looks similar to what we discussed to today on IRC, maybe having a more
> up-to-date development OpenWrt along longer lasting stable releases.
> 
> As currently, OpenWrt is way out of date for kernel development but is moving
> too quickly for keeping the stable releases from regressing.

Which is an interesting paradox.
-- 
Florian



More information about the openwrt-devel mailing list