Message-ID: <e4a9fbc1-93d5-608e-44f4-45c9b64b3503@gmail.com>
Date:   Tue, 26 Jan 2021 09:35:48 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Scott Branden <scott.branden@...adcom.com>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>
Subject: Re: 5.10 LTS Kernel: 2 or 6 years?



On 1/25/2021 11:29 PM, Greg Kroah-Hartman wrote:
> On Mon, Jan 25, 2021 at 11:55:11AM -0800, Scott Branden wrote:
>> Hi All,
>>
>> The 5.10 LTS kernel being officially LTS supported for 2 years presents a problem:
>> why would anyone select a 5.10 kernel with 2 year LTS when 5.4 kernel has a 6 year LTS.
> 
> Because they want to use all of the latest stuff that 5.10 provides
> them.  Don't you want faster and more secure kernels for your devices?
> 
>> Yet, various unofficial reports indicate it will be supported for 6 years.
> 
> Rumors are nice, aren't they :)
> 
>>   And AOSP has already declared the use
>> of 5.10 kernel in their Android S and T releases.
> 
> Publically?  Where?  And is that really the name of the new Android
> releases, I thought they switched to numbers now (hence the naming of
> the current android-common kernel branches, marketing is fun...)
> 
>> Is there some way we could make the LTS support more clear.
>> A 2 year declaration is not LTS any more.
> 
> Not true at all, a "normal" stable kernel is dropped after the next
> release happens, making their lifespan about 4 months long.  2 years is
> much longer than 4 months, so it still is a "long term supported" kernel
> in contrast, correct?
> 
>> If 5.10 is "actually" going to be supported for 6 years it would be quite valuable to make such a declaration.
>> https://www.kernel.org/category/releases.html
> 
> Why?  What would that change?

I believe what Scott is looking for is a form of official statement that
indicates that 5.10 is indeed a 6 years Long Term Stable kernel, as
opposed to an informal piece of information like this:

https://twitter.com/kernellogger/status/1320731458311491587

(personally that is how I got to hear about 5.10 being selected, taking
this with a grain of salt).

> 
> Ok, seriously, this happens every year, and every year we go through the
> same thing, it's not like this is somehow new, right?

It is not new indeed but there is a recurring pattern, and I have been
told by some of our customers who use the kernel.org's releases.html
page that this is how they know which kernel is going to be LTS and plan
ahead accordingly.

If you feel making such a statement actually hurts the kernel project as
a whole, or sort of steers people into cramming all of their desired
features/bug fixes towards particular versions of the kernel that may,
or may not be 6 years LTS, that may be an argument against announcing
before, but maybe not after the kernel is released?

> 
> I want to see companies _using_ the kernel, and most importantly,
> _updating_ their devices with it, to know if it is worth to keep around
> for longer than 2 years.  I also, hopefully, want to see how those
> companies will help me out in the testing and maintenance of that kernel
> version in order to make supporting it for 6 years actually possible.

This really depends on which market you are in we have (Set-top-box and
cable modem) customers that do *want* to use newer kernels but are so
slow in adopting new ones that by the time they start the kernel has
already been phased out 2 years ago.

We have worked (and are still working) with a customer who wanted so
badly 4.1 they rattled our whole organization and had my team on call to
get there, only to start working on it seriously in 2019. The problem
was not necessarily the SoC vendor but the various OEMs and their bigger
pile of out of tree patches and the fact that the platforms were so old
that the essential knowledge of all of their little details was gone
(fired, retired, moved on) already.

6 years provides a great window of time for people to get to a quality
production with the kernel while offering enough time for slow users to
transition over and yet still have a comfortable window of updates. 2
years is a bit too short and will result in the SoC vendor or whoever
gets paid for to either continue support and maybe endorse the
responsibility of doing critical back ports themselves (meltdown,
spectre, etc.) with all the implied liability, or completely drop
support for the unmaintained kernel. In both situations, the device's
security is not as great as if a 6 years LTS kernel had been chosen.

People who can jump on the 2 year stable kernel will, and those who
cannot will not, so having 6 years is a good way to avoid skipping too
much yet try to live with what is/was current at the time.

> 
> So, are you planning on using 5.10?  Will you will be willing to help
> out in testing the -rc releases I make to let me know if there are any
> problems, and to help in pointing out and backporting any specific
> patches that your platforms need for that kernel release?
> 
> When I get this kind of promises and support from companies, then I am
> glad to bump up the length of the kernel support from 2 to 6 years, and
> I mark it on the web site.  Traditionally this happens in Febuary/March
> once I hear from enough companies.  Can I count on your support in this
> endeavor?

I cannot comment on Scott's plan since we don't work in the same
business group, however we have active customers on Set-top-box and
cable modem devices that actively use the 4.9, start adopting 5.4 now
and by the end of this year the 5.10 kernel and I believe you do see me
requesting specific patches to be included once in a while ;). These
customers are a mix of RDK video, Android and just custom made Linux,
they all want a 6 years LTS kernel though because it puts them on a
support timeline they can work with given their pace and kernel expertise.

> 
> Also, a meta-comment.  Please reconsider using a single kernel version
> for longer than 2 years on systems that you actively support and
> maintain.  It's generally a bad idea unless you are stuck with millions
> of out-of-tree code that something like a customer-unfriendly SoC vendor
> provides.  If you are stuck in that type of situation, well they have
> decided to spend extra money to keep their out-of-tree code alive, so
> why are they forcing you to also spend extra money and energy?

We may get paid extra money by said customers to keep maintaining
whatever old kernel they have because it still is cheaper for them than
doing new shipments and deployments of devices in the field. This means
we sell fewer devices to them for a while, but by the same token we have
exclusivity for a while and do not yet open up a window for a new
project to be with a different vendor. Is not that great conflict of
self interest?

The other thing that we have seen, especially with Android is that you
start a project on one of the 3 kernels maintained at the time, get to
market, get maintenance updates on a branch (so many branches) and
that's it, no more updates for you, which is where the 6 year LTS is
sort of handy.

PS: the usual stuff: I am not expressing ideas from my employer here,
just my own.
-- 
Florian

Powered by blists - more mailing lists