From: Florian Fainelli <f.fainelli@gmail.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Scott Branden <scott.branden@broadcom.com> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>, LKML <linux-kernel@vger.kernel.org>, BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com> Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Date: Tue, 26 Jan 2021 09:35:48 -0800 [thread overview] Message-ID: <e4a9fbc1-93d5-608e-44f4-45c9b64b3503@gmail.com> (raw) In-Reply-To: <YA/E1bHRmZb50MlS@kroah.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Scott Branden <scott.branden@broadcom.com> Cc: BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>, LKML <linux-kernel@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Date: Tue, 26 Jan 2021 09:35:48 -0800 [thread overview] Message-ID: <e4a9fbc1-93d5-608e-44f4-45c9b64b3503@gmail.com> (raw) In-Reply-To: <YA/E1bHRmZb50MlS@kroah.com> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-26 18:14 UTC|newest] Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-25 19:55 5.10 LTS Kernel: 2 or 6 years? Scott Branden 2021-01-25 19:55 ` Scott Branden 2021-01-26 2:50 ` Adam Borowski 2021-01-26 2:50 ` Adam Borowski 2021-01-26 7:29 ` Greg Kroah-Hartman 2021-01-26 7:29 ` Greg Kroah-Hartman 2021-01-26 17:35 ` Florian Fainelli [this message] 2021-01-26 17:35 ` Florian Fainelli 2021-01-26 18:30 ` Scott Branden 2021-01-26 18:30 ` Scott Branden 2021-01-26 18:51 ` Greg Kroah-Hartman 2021-01-26 18:51 ` Greg Kroah-Hartman 2021-01-26 20:15 ` Willy Tarreau 2021-01-26 20:15 ` Willy Tarreau 2021-01-29 10:00 ` 10 years -- was " Pavel Machek 2021-02-17 9:40 ` Greg Kroah-Hartman 2021-02-17 9:40 ` Greg Kroah-Hartman 2021-02-17 19:48 ` Scott Branden 2021-02-17 19:48 ` Scott Branden 2021-02-18 7:43 ` Greg Kroah-Hartman 2021-02-18 7:43 ` Greg Kroah-Hartman 2021-02-18 11:31 ` Willy Tarreau 2021-02-18 11:31 ` Willy Tarreau 2021-02-18 14:15 ` Jari Ruusu 2021-02-18 14:15 ` Jari Ruusu 2021-02-18 14:29 ` Greg Kroah-Hartman 2021-02-18 14:29 ` Greg Kroah-Hartman 2021-02-18 20:55 ` Pavel Machek 2021-02-18 20:55 ` Pavel Machek 2021-02-18 22:43 ` Ondrej Zary 2021-02-18 22:43 ` Ondrej Zary 2021-02-19 8:00 ` Pavel Machek 2021-02-19 8:00 ` Pavel Machek 2021-02-19 8:30 ` Greg Kroah-Hartman 2021-02-19 8:30 ` Greg Kroah-Hartman 2021-02-18 14:33 ` Willy Tarreau 2021-02-18 14:33 ` Willy Tarreau 2021-02-18 17:19 ` Jari Ruusu 2021-02-18 17:19 ` Jari Ruusu 2021-02-18 17:22 ` Russell King - ARM Linux admin 2021-02-18 17:22 ` Russell King - ARM Linux admin 2021-02-18 17:44 ` Greg Kroah-Hartman 2021-02-18 17:44 ` Greg Kroah-Hartman 2021-02-19 7:10 ` Jari Ruusu 2021-02-19 7:10 ` Jari Ruusu 2021-02-19 8:22 ` Greg Kroah-Hartman 2021-02-19 8:22 ` Greg Kroah-Hartman 2021-02-19 10:31 ` Jari Ruusu 2021-02-19 10:31 ` Jari Ruusu 2021-02-19 10:37 ` Greg Kroah-Hartman 2021-02-19 10:37 ` Greg Kroah-Hartman 2021-02-19 10:57 ` Jari Ruusu 2021-02-19 10:57 ` Jari Ruusu 2021-02-19 11:16 ` Greg Kroah-Hartman 2021-02-19 11:16 ` Greg Kroah-Hartman 2021-02-19 15:23 ` Jari Ruusu 2021-02-19 15:23 ` Jari Ruusu 2021-02-20 13:29 ` Jari Ruusu 2021-02-20 13:29 ` Jari Ruusu 2021-02-20 16:05 ` Greg Kroah-Hartman 2021-02-20 16:05 ` Greg Kroah-Hartman 2021-02-20 17:06 ` Willy Tarreau 2021-02-20 17:06 ` Willy Tarreau 2021-02-21 11:38 ` Jari Ruusu 2021-02-21 11:38 ` Jari Ruusu 2021-02-19 16:50 ` Theodore Ts'o 2021-02-19 16:50 ` Theodore Ts'o 2021-02-18 17:16 ` Florian Fainelli 2021-02-18 17:16 ` Florian Fainelli 2021-02-18 12:51 ` Pavel Machek 2021-02-18 12:51 ` Pavel Machek 2021-02-18 16:51 ` Sasha Levin 2021-02-18 16:51 ` Sasha Levin 2021-02-18 17:21 ` Florian Fainelli 2021-02-18 17:21 ` Florian Fainelli 2021-02-18 17:53 ` Greg Kroah-Hartman 2021-02-18 17:53 ` Greg Kroah-Hartman 2021-02-18 17:57 ` Florian Fainelli 2021-02-18 17:57 ` Florian Fainelli 2021-02-18 18:20 ` Willy Tarreau 2021-02-18 18:20 ` Willy Tarreau 2021-02-18 18:36 ` Greg Kroah-Hartman 2021-02-18 18:36 ` Greg Kroah-Hartman 2021-02-18 20:16 ` Scott Branden 2021-02-18 20:16 ` Scott Branden 2021-02-18 21:00 ` Willy Tarreau 2021-02-18 21:00 ` Willy Tarreau 2021-02-18 22:38 ` Scott Branden 2021-02-18 22:38 ` Scott Branden 2021-02-18 21:39 ` Sasha Levin 2021-02-18 21:39 ` Sasha Levin 2021-02-18 22:00 ` Florian Fainelli 2021-02-18 22:00 ` Florian Fainelli 2021-02-18 22:26 ` Scott Branden 2021-02-18 22:26 ` Scott Branden 2021-02-19 8:25 ` Greg Kroah-Hartman 2021-02-19 8:25 ` Greg Kroah-Hartman 2021-02-19 15:05 ` Florian Fainelli 2021-02-19 15:05 ` Florian Fainelli 2021-02-19 15:53 ` Greg Kroah-Hartman 2021-02-19 15:53 ` Greg Kroah-Hartman 2021-02-19 17:44 ` Florian Fainelli 2021-02-19 17:44 ` Florian Fainelli 2021-02-22 14:17 ` Greg Kroah-Hartman 2021-02-22 14:17 ` Greg Kroah-Hartman 2021-02-18 17:42 ` Florian Fainelli 2021-02-18 17:42 ` Florian Fainelli 2021-02-18 18:13 ` Willy Tarreau 2021-02-18 18:13 ` Willy Tarreau 2021-02-18 10:04 ` Pavel Machek 2021-02-18 10:04 ` Pavel Machek 2021-01-29 9:49 ` Pavel Machek 2021-02-19 8:54 ` Hanjun Guo 2021-02-19 8:54 ` Hanjun Guo 2021-02-19 9:08 ` Greg Kroah-Hartman 2021-02-19 9:08 ` Greg Kroah-Hartman 2021-02-20 7:02 ` Hanjun Guo 2021-02-20 7:02 ` Hanjun Guo 2021-02-20 9:53 ` Greg Kroah-Hartman 2021-02-20 9:53 ` Greg Kroah-Hartman 2021-02-23 2:14 ` Hanjun Guo 2021-02-23 2:14 ` Hanjun Guo 2021-02-19 14:45 ` Nikolai Kondrashov 2021-02-19 14:45 ` Nikolai Kondrashov 2021-02-26 8:03 ` Hanjun Guo 2021-02-26 8:03 ` Hanjun Guo 2021-02-26 8:03 ` Hanjun Guo 2021-02-26 11:21 ` Nikolai Kondrashov 2021-02-26 11:21 ` Nikolai Kondrashov 2021-02-22 14:00 ` Nishanth Aravamudan 2021-02-22 14:00 ` Nishanth Aravamudan 2021-02-22 14:24 ` Greg Kroah-Hartman 2021-02-22 14:24 ` Greg Kroah-Hartman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=e4a9fbc1-93d5-608e-44f4-45c9b64b3503@gmail.com \ --to=f.fainelli@gmail.com \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=scott.branden@broadcom.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.