Greetings!
I'm working on the 2nd edition of the Linux Kernel Programming book
(https://www.amazon.com/gp/product/B07RW915K4/ref=dbs_a_def_rwt_bibl_vppi_i0)
and request your help...
I'd like to base the book upon as recent a kernel version as is
feasible, of course, with the caveat that it's a long-term (LTS) one
that will be around for a while. Currently, the 5.10 LTS kernel's EOL
date - Dec 2026 - makes it an ideal candidate.
However, if possible, I'd (also) like to use a 6.x kernel; so, my
question comes down to this: will a 6.1 kernel release occur soon (I
heard it should be around Dec this year)? Will it be an LTS kernel
(again, should be I guess), and, if so, very important for me, what's
the likely EOL date?
Much appreciate your time, TIA.
T&R,
Kaiwan.
Please reconsidrer using 6.1 as the next LTS.
6.0 or 5.19 is much more fitting due to not having Rust support, a
major change. A lot of the community is hesitant on how Rust will
work and it would be nice to have a non-Rust capable LTS besides 5.15
since that is already one year old. Having a more recent non-Rust
capable LTS would make the transition more smooth as it provides a
couple years for those of us that are hesitant to see if it goes down
well or who knows, gets ejected altogether.
Thank you for your consideration,
Carl
On Fri, Oct 07, 2022 at 11:04:04AM -0400, Carl Dasantas wrote:
> Please reconsidrer using 6.1 as the next LTS.
>
> 6.0 or 5.19 is much more fitting due to not having Rust support, a
> major change.
That makes no sense at all given what Rust code will be in 6.1. Did you
look at it? What specific functionality does it provide that is going
to be a problem for ANY platform that Linux currently supports?
greg k-h
On Fri, Oct 07, 2022 at 12:07:05PM -0400, Carl Dasantas wrote:
> It's moreso the fact that initial Rust support is being added.
Again, specifics, I do not think you actually looked at the code as your
next sentance does not reflect reality:
> Yes I know it's just initial support/NVMe drivers.
That is not true, please look at the code.
Feel free to disable it if you don't like it, we do not do LTS releases
based on content, but rather time.
thanks,
greg k-h
It's moreso the fact that initial Rust support is being added. Yes I
know it's just initial support/NVMe drivers. The point is that it is a
major change to have another language support added. 6.0 to 6.1 is
clearly the cut off between no Rust at all and *intiail* Rust support.
I wasn't around back when C++ was added and ejected, but what was the
process then? An LTS that is very old prior to C++ > C++ added
*intiially* LTS made > C++ ejected? For those that might have been
hesitant on C++ they could have stayed on an LTS right before C++ was
added and then just skipped any potential issues and went right to the
next LTS after it was removed. Also, Rust support isn't the only major
change in 6.1, by the kernel.orgs own site (time permitting) an LTS is
made if major changes are present. In my opinion, which I am sure
means nothing to most of you but echoes a lot of others, if anything
as a gesture of goodwill towards the community an LTS should be made
prior to any Rust support being added aka 5.19 or 6.0.
Carl
On Fri, Oct 7, 2022 at 11:35 AM Greg KH <[email protected]> wrote:
>
> On Fri, Oct 07, 2022 at 11:04:04AM -0400, Carl Dasantas wrote:
> > Please reconsidrer using 6.1 as the next LTS.
> >
> > 6.0 or 5.19 is much more fitting due to not having Rust support, a
> > major change.
>
> That makes no sense at all given what Rust code will be in 6.1. Did you
> look at it? What specific functionality does it provide that is going
> to be a problem for ANY platform that Linux currently supports?
>
> greg k-h
Hi,
This is now at least the third email I've gotten about Rust support in
the kernel. I've been ignoring them, but I'd like to say something now
and leave it at that.
On 10/7/22 at 11:04 AM, Carl Dasantas wrote:
> Please reconsidrer using 6.1 as the next LTS.
>
> 6.0 or 5.19 is much more fitting due to not having Rust support, a
> major change. A lot of the community is hesitant on how Rust will
> work and it would be nice to have a non-Rust capable LTS besides 5.15
> since that is already one year old. Having a more recent non-Rust
> capable LTS would make the transition more smooth as it provides a
> couple years for those of us that are hesitant to see if it goes down
> well or who knows, gets ejected altogether.
The most recent pull request for Rust support was by no means a major
change, it was _only initial support_ for Rust, nothing more than that.
Maybe I'm wrong, but after reading Kees's pull request[1], and reviewing
all the changes (which I also recommend you do, I've dropped a link
below!): it's all minor in the grand scheme of things. It's not changing
much as of me writing this.
Greg, who handles stable releases, doesn't do stable/longterm releases
based on significance, but rather, time. IOW, the yearly LTS kernel is
usually "last kernel of the year." (Greg's words, not mine.) Right now,
that appears to be 6.1 and may or may not stay that way.
I'm truly sorry you (and others, obviously) feel that way about Rust --
I'm not going to weigh in further because I don't have enough experience
with it yet -- but I really don't think it's going anywhere anytime soon.
Thanks,
-srw
[1] https://lore.kernel.org/lkml/202210010816.1317F2C@keescook/
On Fri, Oct 07, 2022 at 12:07:05PM -0400, Carl Dasantas wrote:
> It's moreso the fact that initial Rust support is being added. Yes I
> know it's just initial support/NVMe drivers.
Care to name a *single* functional kernel feature (whether a device
driver or not) that is dependent on RUST. Have you tried building the
latest development kernel without rust --- what happens? (hint: nothing)
> Also, Rust support isn't the only major
> change in 6.1, by the kernel.orgs own site (time permitting) an LTS is
> made if major changes are present.
This is simply not true. The start of a new LTS kernel has always
been time-based, and there certainly have been attempts to get new
major functionality around this time of year in the hopes that it can
be made avcailable in distro kernels. Of course, if the functionality
or change is too flaky, it could very well get reverted or the
distributions will simply not enable the feature because it would be a
support nightmare for them.
All of this does not apply for Rust. Again, take a look at what is
*actually* been included during the current merge window.
Regards,
- Ted
On Sat, Dec 17, 2022 at 06:32:48PM +0530, Kaiwan N Billimoria wrote:
> Hi,
> Any update on 6.1 being set as the next LTS release?
You tell me please. How has your testing gone for 6.1 so far? Does it
work properly for you? Are you and/or your company willing to test out
the -rc releases and provide feedback if it works or not for your
systems? Do you have problems with 6.1.y vs. older kernels? Is there
anything missing in it that you feel needs to be addressed with a newer
kernel instead?
thanks,
greg k-h
:-) Got it.
Taking your point into account, I'll rephrase: as the _convention_ is
to mark the last release in the year as LTS, is there any visibility
on when, or if, it comes about?
Thanks,
Kaiwan
On Sat, Dec 17, 2022 at 6:48 PM Greg KH <[email protected]> wrote:
>
> On Sat, Dec 17, 2022 at 06:32:48PM +0530, Kaiwan N Billimoria wrote:
> > Hi,
> > Any update on 6.1 being set as the next LTS release?
>
> You tell me please. How has your testing gone for 6.1 so far? Does it
> work properly for you? Are you and/or your company willing to test out
> the -rc releases and provide feedback if it works or not for your
> systems? Do you have problems with 6.1.y vs. older kernels? Is there
> anything missing in it that you feel needs to be addressed with a newer
> kernel instead?
>
> thanks,
>
> greg k-h
On Sat, Dec 17, 2022 at 07:14:14PM +0530, Kaiwan N Billimoria wrote:
> :-) Got it.
> Taking your point into account, I'll rephrase: as the _convention_ is
> to mark the last release in the year as LTS, is there any visibility
> on when, or if, it comes about?
What Greg tried to explain to you is that the convention is to pick a
sufficiently well tested kernel to make sure its maintenance will not
become a huge burden, and that it cannot be a single-person effort,
testers are needed during that period. As such companies and/or users
engaging in investing some resources for testing are extremely
important and if some have a good reason to prefer investing that time
on a different kernel, their choice will count more than just a kind
request on the mailing list. Now you know how to make your voice count
if you want/need 6.1 to become LTS.
Regards,
Willy
On Sat, Dec 17, 2022 at 07:14:14PM +0530, Kaiwan N Billimoria wrote:
> :-) Got it.
Sorry, but you didn't answer any of my questions, which makes it
impossible for me to answer yours as my answer depends on your answer.
Also, top-posting is bad, as you know, you just lost all the context
here :(
thanks,
greg k-h
On Sat, Dec 17, 2022 at 10:11 PM Willy Tarreau <[email protected]> wrote:
>
> On Sat, Dec 17, 2022 at 07:14:14PM +0530, Kaiwan N Billimoria wrote:
> > :-) Got it.
> > Taking your point into account, I'll rephrase: as the _convention_ is
> > to mark the last release in the year as LTS, is there any visibility
> > on when, or if, it comes about?
>
> What Greg tried to explain to you is that the convention is to pick a
> sufficiently well tested kernel to make sure its maintenance will not
> become a huge burden, and that it cannot be a single-person effort,
> testers are needed during that period. As such companies and/or users
> engaging in investing some resources for testing are extremely
> important and if some have a good reason to prefer investing that time
> on a different kernel, their choice will count more than just a kind
> request on the mailing list. Now you know how to make your voice count
> if you want/need 6.1 to become LTS.
>
Willy, Greg K-H, thanks for your guidance,
Kaiwan.
> Regards,
> Willy
Hey Greg,
You didn't ask me specifically, but if it helps...
On Sat, Dec 17, 2022 at 02:18:30PM +0100, Greg KH wrote:
> On Sat, Dec 17, 2022 at 06:32:48PM +0530, Kaiwan N Billimoria wrote:
> > Hi,
> > Any update on 6.1 being set as the next LTS release?
>
> You tell me please. How has your testing gone for 6.1 so far?
> Does it work properly for you?
AFIACT, it does. We had some issues, but they've since been resolved.
> Are you and/or your company willing to test out
> the -rc releases and provide feedback if it works or not for your
> systems?
Already do! Although so far I've just been reporting breakages rather
than providing tested-bys.
> Do you have problems with 6.1.y vs. older kernels?
Nope, anything that needed fixing that was on my radar has already made
it into 6.1.y.
> Is there
> anything missing in it that you feel needs to be addressed with a newer
> kernel instead?
Anything missing on the RISC-V side of things, that we would want, is
still a work in progress for kernels later than 6.2 anyway.
Hope that helps,
Conor.
On Wed, Jan 11, 2023 at 08:15:23AM +0000, Conor Dooley wrote:
> Hey Greg,
>
> You didn't ask me specifically, but if it helps...
It really really does, thank you!
> On Sat, Dec 17, 2022 at 02:18:30PM +0100, Greg KH wrote:
> > On Sat, Dec 17, 2022 at 06:32:48PM +0530, Kaiwan N Billimoria wrote:
> > > Hi,
> > > Any update on 6.1 being set as the next LTS release?
> >
> > You tell me please. How has your testing gone for 6.1 so far?
> > Does it work properly for you?
>
> AFIACT, it does. We had some issues, but they've since been resolved.
Great!
> > Are you and/or your company willing to test out
> > the -rc releases and provide feedback if it works or not for your
> > systems?
>
> Already do! Although so far I've just been reporting breakages rather
> than providing tested-bys.
Feel free to submit a tested-by if you want credit for doing the work
(and so that I know it still is working), I'm more than glad to collect
them all as they end up in the release commit message in the kernel log.
One example can be seen here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=2cb8e624295ffa0c4d659fcec7d9e7a6c48de156
> > Do you have problems with 6.1.y vs. older kernels?
>
> Nope, anything that needed fixing that was on my radar has already made
> it into 6.1.y.
>
> > Is there
> > anything missing in it that you feel needs to be addressed with a newer
> > kernel instead?
>
> Anything missing on the RISC-V side of things, that we would want, is
> still a work in progress for kernels later than 6.2 anyway.
that's great to hear, thanks for letting me know and for testing.
greg k-h
On Wed, Jan 11, 2023 at 12:33:38PM +0100, Greg KH wrote:
> On Wed, Jan 11, 2023 at 08:15:23AM +0000, Conor Dooley wrote:
> > Already do! Although so far I've just been reporting breakages rather
> > than providing tested-bys.
> Feel free to submit a tested-by if you want credit for doing the work
Yah, IDC much about getting the credit, saving myself work if something
broken lands downstream is the goal!
There's no real overhead to doing it though, so I suppose I may as well!
Hello Greg,
> You tell me please. How has your testing gone for 6.1 so far? Does it
> work properly for you? Are you and/or your company willing to test out
> the -rc releases and provide feedback if it works or not for your
> systems? Do you have problems with 6.1.y vs. older kernels? Is there
> anything missing in it that you feel needs to be addressed with a newer
> kernel instead?
We have been integrating and testing 6.1 on the Microblaze, ARM32 and
ARM64-bit architectures over the past few weeks. These builds have
been successful and we are able to run our regression tests on hardware
targeting our FPGA SoC devices.
We're continuing our tests as new updates to the 6.1 kernel series
appear.
Hope that information is of use.
Kris Chaplin - Xilinx/AMD
Hi Greg,
On 1/12/23 13:23, Kris Chaplin wrote:
> Hello Greg,
>
>> You tell me please. How has your testing gone for 6.1 so far? Does it
>> work properly for you? Are you and/or your company willing to test out
>> the -rc releases and provide feedback if it works or not for your
>> systems? Do you have problems with 6.1.y vs. older kernels? Is there
>> anything missing in it that you feel needs to be addressed with a newer
>> kernel instead?
>
> We have been integrating and testing 6.1 on the Microblaze, ARM32 and
> ARM64-bit architectures over the past few weeks. These builds have
> been successful and we are able to run our regression tests on hardware
> targeting our FPGA SoC devices.
>
> We're continuing our tests as new updates to the 6.1 kernel series
> appear.
As Kris said AMD/Xilinx has already moved internal SOC tree to 6.1 based kernel
in expectation that 6.1 will become next LTS.
And I am not aware about any issue from testing team related to 6.1 kernel
version. And we are covering our AMD/Xilinx SOCs based on arm32/arm64 and
Microblaze CPUs.
It would be good to continue with the same strategy which using the latest
kernel at that year which is what I am hearing all the time from others that 6.1
was last kernel at that year and it should be LTS.
I didn't run any stats but normally also more patches are going to this version
to be the part of LTS.
We will be upgrading to the latest stable version 6.1.5 quite soon but normally
there are no new issues coming from it.
Thanks,
Michal
On Thu, Jan 12, 2023 at 12:23:46PM +0000, Kris Chaplin wrote:
> Hello Greg,
>
> > You tell me please. How has your testing gone for 6.1 so far? Does it
> > work properly for you? Are you and/or your company willing to test out
> > the -rc releases and provide feedback if it works or not for your
> > systems? Do you have problems with 6.1.y vs. older kernels? Is there
> > anything missing in it that you feel needs to be addressed with a newer
> > kernel instead?
>
> We have been integrating and testing 6.1 on the Microblaze, ARM32 and
> ARM64-bit architectures over the past few weeks. These builds have
> been successful and we are able to run our regression tests on hardware
> targeting our FPGA SoC devices.
>
> We're continuing our tests as new updates to the 6.1 kernel series
> appear.
>
> Hope that information is of use.
It is very much so, thanks! And if you can provide "tested-by" results
for the -rc releases, that would help even more to verify that we aren't
breaking anything over time.
greg k-h
On Thu, Jan 12, 2023 at 01:26:28PM +0100, Michal Simek wrote:
> Hi Greg,
>
> On 1/12/23 13:23, Kris Chaplin wrote:
> > Hello Greg,
> >
> > > You tell me please.? How has your testing gone for 6.1 so far?? Does it
> > > work properly for you?? Are you and/or your company willing to test out
> > > the -rc releases and provide feedback if it works or not for your
> > > systems?? Do you have problems with 6.1.y vs. older kernels?? Is there
> > > anything missing in it that you feel needs to be addressed with a newer
> > > kernel instead?
> >
> > We have been integrating and testing 6.1 on the Microblaze, ARM32 and
> > ARM64-bit architectures over the past few weeks.? These builds have
> > been successful and we are able to run our regression tests on hardware
> > targeting our FPGA SoC devices.
> >
> > We're continuing our tests as new updates to the 6.1 kernel series
> > appear.
>
> As Kris said AMD/Xilinx has already moved internal SOC tree to 6.1 based
> kernel in expectation that 6.1 will become next LTS.
> And I am not aware about any issue from testing team related to 6.1 kernel
> version. And we are covering our AMD/Xilinx SOCs based on arm32/arm64 and
> Microblaze CPUs.
>
> It would be good to continue with the same strategy which using the latest
> kernel at that year which is what I am hearing all the time from others that
> 6.1 was last kernel at that year and it should be LTS.
Generally yes, I pick the last release of the year but we need people to
verify and validate that both it works for them, and that they are going
to be using it in their systems and can provide testing results to us
(as well as providing a way for their devices to actually be updated to
the new releases, we've had previous stable kernel releases that were
never actually shipped out to devices...)
> I didn't run any stats but normally also more patches are going to this
> version to be the part of LTS.
What do you mean by this? The patches accepted so far since 6.1.0 was
released, or up until 6.1.0 was released? For the patches since 6.1.0
was released, that's due to more developers/maintainers tagging patches
during the -rc1 merge window for stable releases (honestly they should
have gotten them into the -final release first), and due to us having
better tools in digging up potential stable patches (i.e. Sasha's
AUTOSEL bot work.)
thanks,
greg k-h
On 1/13/23 12:27, Greg KH wrote:
> On Thu, Jan 12, 2023 at 01:26:28PM +0100, Michal Simek wrote:
>> Hi Greg,
>>
>> On 1/12/23 13:23, Kris Chaplin wrote:
>>> Hello Greg,
>>>
>>>> You tell me please. How has your testing gone for 6.1 so far? Does it
>>>> work properly for you? Are you and/or your company willing to test out
>>>> the -rc releases and provide feedback if it works or not for your
>>>> systems? Do you have problems with 6.1.y vs. older kernels? Is there
>>>> anything missing in it that you feel needs to be addressed with a newer
>>>> kernel instead?
>>>
>>> We have been integrating and testing 6.1 on the Microblaze, ARM32 and
>>> ARM64-bit architectures over the past few weeks. These builds have
>>> been successful and we are able to run our regression tests on hardware
>>> targeting our FPGA SoC devices.
>>>
>>> We're continuing our tests as new updates to the 6.1 kernel series
>>> appear.
>>
>> As Kris said AMD/Xilinx has already moved internal SOC tree to 6.1 based
>> kernel in expectation that 6.1 will become next LTS.
>> And I am not aware about any issue from testing team related to 6.1 kernel
>> version. And we are covering our AMD/Xilinx SOCs based on arm32/arm64 and
>> Microblaze CPUs.
>>
>> It would be good to continue with the same strategy which using the latest
>> kernel at that year which is what I am hearing all the time from others that
>> 6.1 was last kernel at that year and it should be LTS.
>
> Generally yes, I pick the last release of the year but we need people to
> verify and validate that both it works for them, and that they are going
> to be using it in their systems and can provide testing results to us
> (as well as providing a way for their devices to actually be updated to
> the new releases, we've had previous stable kernel releases that were
> never actually shipped out to devices...)
We are preparing base (every year) for our customers which is what it is also
shipped in our distribution.
Other distribution like Ubuntu with their derivative kernels prefer to stay on
the LTS kernels too.
Also users will be getting fixes against our base for extended period with fixes
going from vanilla kernel.
For code which is not upstream(which we unfortunately have it) we are providing
fixes only till the next LTS version base is created.
That's why it is very beneficial to use for our base kernel which is going to be
LTS that users will get that extended period support.
Base Kernel version is taken after your decision about LTS. But this year
because of timing we couldn't wait for this decision. That's why 6.1 was taken
with expectation that your generic concept about picking up the last release of
the year is going to continue.
Tested wise. We have test result from 6.1 <.0> and I have also shared 6.1.5
based version for our distribution. As of today we can't see any issue with 6.1
kernel in general on features which we are using on AMD/Xilinx SOCs.
Also Jonathan wrote at https://lwn.net/Articles/915435/
"Unless something extremely surprising happens, 6.1 will be the final kernel
release for 2022, and thus will become the next LTS kernel."
That's why I hope that 6.1 is going to be next LTS.
>
>> I didn't run any stats but normally also more patches are going to this
>> version to be the part of LTS.
>
> What do you mean by this? The patches accepted so far since 6.1.0 was
> released, or up until 6.1.0 was released? For the patches since 6.1.0
> was released, that's due to more developers/maintainers tagging patches
> during the -rc1 merge window for stable releases (honestly they should
> have gotten them into the -final release first), and due to us having
> better tools in digging up potential stable patches (i.e. Sasha's
> AUTOSEL bot work.)
I am just saying that developers/driver owners can simple do calculation to
identify LTS version. When they know it they also know time when their deadline
is for upstreaming work. It means if patch is accepted between 6.0-r1 and
6.0-rc5/6 they know that it will get to 6.1 merge window.
And by this there will be less patches pending for the next release upgrade.
I am not working in this mood but I have met with it couple of times.
Thanks,
Michal
On Fri, Jan 13, 2023 at 01:54:29PM +0100, Michal Simek wrote:
>
>
> On 1/13/23 12:27, Greg KH wrote:
> > On Thu, Jan 12, 2023 at 01:26:28PM +0100, Michal Simek wrote:
> > > Hi Greg,
> > >
> > > On 1/12/23 13:23, Kris Chaplin wrote:
> > > > Hello Greg,
> > > >
> > > > > You tell me please.? How has your testing gone for 6.1 so far?? Does it
> > > > > work properly for you?? Are you and/or your company willing to test out
> > > > > the -rc releases and provide feedback if it works or not for your
> > > > > systems?? Do you have problems with 6.1.y vs. older kernels?? Is there
> > > > > anything missing in it that you feel needs to be addressed with a newer
> > > > > kernel instead?
> > > >
> > > > We have been integrating and testing 6.1 on the Microblaze, ARM32 and
> > > > ARM64-bit architectures over the past few weeks.? These builds have
> > > > been successful and we are able to run our regression tests on hardware
> > > > targeting our FPGA SoC devices.
> > > >
> > > > We're continuing our tests as new updates to the 6.1 kernel series
> > > > appear.
> > >
> > > As Kris said AMD/Xilinx has already moved internal SOC tree to 6.1 based
> > > kernel in expectation that 6.1 will become next LTS.
> > > And I am not aware about any issue from testing team related to 6.1 kernel
> > > version. And we are covering our AMD/Xilinx SOCs based on arm32/arm64 and
> > > Microblaze CPUs.
> > >
> > > It would be good to continue with the same strategy which using the latest
> > > kernel at that year which is what I am hearing all the time from others that
> > > 6.1 was last kernel at that year and it should be LTS.
> >
> > Generally yes, I pick the last release of the year but we need people to
> > verify and validate that both it works for them, and that they are going
> > to be using it in their systems and can provide testing results to us
> > (as well as providing a way for their devices to actually be updated to
> > the new releases, we've had previous stable kernel releases that were
> > never actually shipped out to devices...)
>
> We are preparing base (every year) for our customers which is what it is
> also shipped in our distribution.
What distribution does AMD create? Who uses it? Where is it published
and how is it updated?
> Other distribution like Ubuntu with their derivative kernels prefer to stay
> on the LTS kernels too.
I already discuss this with the various "normal" distributions all the
time so they know what is going on here already.
> Also users will be getting fixes against our base for extended period with
> fixes going from vanilla kernel.
What is "your base"? Who uses this? How long is it supported?
> For code which is not upstream(which we unfortunately have it) we are
> providing fixes only till the next LTS version base is created.
So you only support the image for one year?
> That's why it is very beneficial to use for our base kernel which is going
> to be LTS that users will get that extended period support.
But you should be keeping this up to date for each normal release,
right? Never do only yearly jumps, that way causes way too much work
and is proven to be a bad idea.
And why not just update your "customers" to every normal release? Why
stick them with one a year? What is preventing more frequent updates?
> Base Kernel version is taken after your decision about LTS. But this year
> because of timing we couldn't wait for this decision. That's why 6.1 was
> taken with expectation that your generic concept about picking up the last
> release of the year is going to continue.
That's a great guess, but again, you should always be updating your
out-of-tree changes against every release so it will not matter what
kernel is picked as a stable one or not.
> Tested wise. We have test result from 6.1 <.0> and I have also shared 6.1.5
> based version for our distribution. As of today we can't see any issue with
> 6.1 kernel in general on features which we are using on AMD/Xilinx SOCs.
Great, can you also test the -rc releases to make sure we don't break
anything for your systems?
> Also Jonathan wrote at https://lwn.net/Articles/915435/
> "Unless something extremely surprising happens, 6.1 will be the final kernel
> release for 2022, and thus will become the next LTS kernel."
> That's why I hope that 6.1 is going to be next LTS.
Testing and feedback is going to be what allows this to happen. I can't
happen in a vacuum, and nor should you want it to.
> > > I didn't run any stats but normally also more patches are going to this
> > > version to be the part of LTS.
> >
> > What do you mean by this? The patches accepted so far since 6.1.0 was
> > released, or up until 6.1.0 was released? For the patches since 6.1.0
> > was released, that's due to more developers/maintainers tagging patches
> > during the -rc1 merge window for stable releases (honestly they should
> > have gotten them into the -final release first), and due to us having
> > better tools in digging up potential stable patches (i.e. Sasha's
> > AUTOSEL bot work.)
>
> I am just saying that developers/driver owners can simple do calculation to
> identify LTS version. When they know it they also know time when their
> deadline is for upstreaming work. It means if patch is accepted between
> 6.0-r1 and 6.0-rc5/6 they know that it will get to 6.1 merge window.
That is what I am afraid of and if it causes problems I will purposfully
pick the previous release. This has happened in the past and is never
an excuse to get anything merged. Code gets merged when it is ready,
not based on a LTS release.
thanks,
greg k-h
On Fri, Jan 13, 2023 at 05:22:56PM +0100, Greg KH wrote:
> > I am just saying that developers/driver owners can simple do calculation to
> > identify LTS version. When they know it they also know time when their
> > deadline is for upstreaming work. It means if patch is accepted between
> > 6.0-r1 and 6.0-rc5/6 they know that it will get to 6.1 merge window.
>
> That is what I am afraid of and if it causes problems I will purposfully
> pick the previous release. This has happened in the past and is never
> an excuse to get anything merged. Code gets merged when it is ready,
> not based on a LTS release.
This is probably the best reason not to preannounce when the LTS
release will be ahead of time --- because it can be abused by
developers who try to get not-ready-for-prime-time features into what
they think will be the LTS kernel, with the result that the last
release of the year could be utterly unsitable for that perpose.
What I would try to tell people who are trying to get a feature into
the enterprise distro kernel is to target a release in the *middle*a
of the year, so that there is plenty of time to stablize it before the
LTS kernel is cut.
Alternatively, I might work with the team reasponsible for release
engineering the "product" kernel that I might be targetting (for
example, for my company's Cloud Optimized OS) and since they follow
the "upstream first" principle, once the feature is upstream, they
will backport it into the various LTS release which we support for our
cloud customers. And if it just so happens that Amazon Linux doesn't
have the feature, but my company's cloud OS does ---- well, that's the
way the cookie crumbles, and that's why the wise distro company will
have kernel developers on staff, not just try to freeload off of the
LTS maintainers. :-)
- Ted
P.S. And if you work for a hardware company, in general the LTS
maintainers have been willing to handle backporting device drivers to
older LTS kernels, since your customers might very well might want to
stay on 5.15, 5.10, 5.4, etc. Of course, if your feature requires
massive surgery all over the kernel, that's even more of a reason not
incentivize people to make massive, risky changes right before the LTS
kernel is cut.
On Fri, Jan 13, 2023 at 04:40:19PM -0500, Theodore Ts'o wrote:
> On Fri, Jan 13, 2023 at 05:22:56PM +0100, Greg KH wrote:
> > > I am just saying that developers/driver owners can simple do calculation to
> > > identify LTS version. When they know it they also know time when their
> > > deadline is for upstreaming work. It means if patch is accepted between
> > > 6.0-r1 and 6.0-rc5/6 they know that it will get to 6.1 merge window.
> >
> > That is what I am afraid of and if it causes problems I will purposfully
> > pick the previous release. This has happened in the past and is never
> > an excuse to get anything merged. Code gets merged when it is ready,
> > not based on a LTS release.
>
> This is probably the best reason not to preannounce when the LTS
> release will be ahead of time --- because it can be abused by
> developers who try to get not-ready-for-prime-time features into what
> they think will be the LTS kernel, with the result that the last
> release of the year could be utterly unsitable for that perpose.
We know this risk exists but since Greg never makes promises on any
version, it remains reasonable. For users who have to rebase some local
patches and run tests, it's still quite important to have a good enough
idea about what version to start working on. It also encourages them to
test the expected version earlier and possibly return more feedback
during the -rc cycle. I did this for 4.9 and 5.10. We all know that
making a good release is a collective effort, and that as such, getting
forces aligned on one version is helpful. However if the engagement is
too strong there's a risk that everyone relies on others. As such I
think the current approach is the most balanced one. All those who
follow the kernel development have reasonably good confidence about what
the version will be, are willing to assign a bit of time to it and their
participation contributes to making it suitable for becoming LTS. And if
nobody cares about it, there's no need for it to become LTS and be
maintained by a single person. And this approach keeps away all those
only interested in "my manager asks me what the next version will be".
> What I would try to tell people who are trying to get a feature into
> the enterprise distro kernel is to target a release in the *middle*a
> of the year, so that there is plenty of time to stablize it before the
> LTS kernel is cut.
Definitely! It's also important to let people know that if they push
too much stuff at once, it's the best way for this stuff never being
reviewed by lack of reviewers time, hence not being merged. Thus
pushing too much too late will never work for an LTS release.
Willy
On Sat, Jan 14, 2023 at 08:14:12AM +0100, Willy Tarreau wrote:
> On Fri, Jan 13, 2023 at 04:40:19PM -0500, Theodore Ts'o wrote:
> > On Fri, Jan 13, 2023 at 05:22:56PM +0100, Greg KH wrote:
> > > > I am just saying that developers/driver owners can simple do calculation to
> > > > identify LTS version. When they know it they also know time when their
> > > > deadline is for upstreaming work. It means if patch is accepted between
> > > > 6.0-r1 and 6.0-rc5/6 they know that it will get to 6.1 merge window.
> > >
> > > That is what I am afraid of and if it causes problems I will purposfully
> > > pick the previous release. This has happened in the past and is never
> > > an excuse to get anything merged. Code gets merged when it is ready,
> > > not based on a LTS release.
> >
> > This is probably the best reason not to preannounce when the LTS
> > release will be ahead of time --- because it can be abused by
> > developers who try to get not-ready-for-prime-time features into what
> > they think will be the LTS kernel, with the result that the last
> > release of the year could be utterly unsitable for that perpose.
>
> We know this risk exists but since Greg never makes promises on any
> version, it remains reasonable.
I have to _not_ make promises because in the past when I did, people
threw crap into the kernel with the "justification" that they had to get
it in this specific kernel because it was going to be the LTS one.
We can't have nice things, because people abuse it :(
greg k-h
On Sat, Jan 14, 2023 at 09:26:07AM +0100, Greg KH wrote:
> On Sat, Jan 14, 2023 at 08:14:12AM +0100, Willy Tarreau wrote:
> > On Fri, Jan 13, 2023 at 04:40:19PM -0500, Theodore Ts'o wrote:
> > > On Fri, Jan 13, 2023 at 05:22:56PM +0100, Greg KH wrote:
> > > > > I am just saying that developers/driver owners can simple do calculation to
> > > > > identify LTS version. When they know it they also know time when their
> > > > > deadline is for upstreaming work. It means if patch is accepted between
> > > > > 6.0-r1 and 6.0-rc5/6 they know that it will get to 6.1 merge window.
> > > >
> > > > That is what I am afraid of and if it causes problems I will purposfully
> > > > pick the previous release. This has happened in the past and is never
> > > > an excuse to get anything merged. Code gets merged when it is ready,
> > > > not based on a LTS release.
> > >
> > > This is probably the best reason not to preannounce when the LTS
> > > release will be ahead of time --- because it can be abused by
> > > developers who try to get not-ready-for-prime-time features into what
> > > they think will be the LTS kernel, with the result that the last
> > > release of the year could be utterly unsitable for that perpose.
> >
> > We know this risk exists but since Greg never makes promises on any
> > version, it remains reasonable.
>
> I have to _not_ make promises because in the past when I did, people
> threw crap into the kernel with the "justification" that they had to get
> it in this specific kernel because it was going to be the LTS one.
>
> We can't have nice things, because people abuse it :(
Absolutely, that was exactly my point :-)
And quite frankly it's better the current way, because you have the
flexibility to change your mind on a given version if during the first
months you discover it's too crappy and will be a maintenance nightmare.
Willy
On 1/13/23 22:40, Theodore Ts'o wrote:
> On Fri, Jan 13, 2023 at 05:22:56PM +0100, Greg KH wrote:
>>> I am just saying that developers/driver owners can simple do calculation to
>>> identify LTS version. When they know it they also know time when their
>>> deadline is for upstreaming work. It means if patch is accepted between
>>> 6.0-r1 and 6.0-rc5/6 they know that it will get to 6.1 merge window.
>>
>> That is what I am afraid of and if it causes problems I will purposfully
>> pick the previous release. This has happened in the past and is never
>> an excuse to get anything merged. Code gets merged when it is ready,
>> not based on a LTS release.
>
> This is probably the best reason not to preannounce when the LTS
> release will be ahead of time --- because it can be abused by
> developers who try to get not-ready-for-prime-time features into what
> they think will be the LTS kernel, with the result that the last
> release of the year could be utterly unsitable for that perpose.
None is saying that not-ready-for-prime-time feature is pushed.
In our case all code before upstream goes to soc vendor and it stays there for
quite a long time when developers have time to upstream it.
I can imagine that this can happen when you use upstream first solution where
the code is not fully tested on all configurations.
>
> What I would try to tell people who are trying to get a feature into
> the enterprise distro kernel is to target a release in the *middle*a
> of the year, so that there is plenty of time to stablize it before the
> LTS kernel is cut.
>> Alternatively, I might work with the team reasponsible for release
> engineering the "product" kernel that I might be targetting (for
> example, for my company's Cloud Optimized OS) and since they follow
> the "upstream first" principle, once the feature is upstream, they
> will backport it into the various LTS release which we support for our
> cloud customers. And if it just so happens that Amazon Linux doesn't
> have the feature, but my company's cloud OS does ---- well, that's the
> way the cookie crumbles, and that's why the wise distro company will
> have kernel developers on staff, not just try to freeload off of the
> LTS maintainers. :-)
We are a little bit different case. We are pretty much not making products. We
are doing SOC enablement to show the latest features on the latest silicon.
But our customers/users are making products based on code we developed for them.
That's why I am telling to developers to upstream code whenever it is ready to
be upstreamed but not everybody is following recommendations . And for new SOCs
we should be couple of months ahead for any customer that's why it shouldn't
really matter if that feature goes to one or another kernel.
>
> - Ted
>
> P.S. And if you work for a hardware company, in general the LTS
> maintainers have been willing to handle backporting device drivers to
> older LTS kernels, since your customers might very well might want to
> stay on 5.15, 5.10, 5.4, etc. Of course, if your feature requires
> massive surgery all over the kernel, that's even more of a reason not
> incentivize people to make massive, risky changes right before the LTS
> kernel is cut.
This is the first time when I hear about it. I think that LTSI kernel guys for
supporting kernel for extended period they are doing it but never heard that it
can be also done for regular LTS kernels.
Anyway we don't need it but it is good to be aware about it.
Thanks,
Michal
On 1/13/23 17:22, Greg KH wrote:
> On Fri, Jan 13, 2023 at 01:54:29PM +0100, Michal Simek wrote:
>>
>>
>> On 1/13/23 12:27, Greg KH wrote:
>>> On Thu, Jan 12, 2023 at 01:26:28PM +0100, Michal Simek wrote:
>>>> Hi Greg,
>>>>
>>>> On 1/12/23 13:23, Kris Chaplin wrote:
>>>>> Hello Greg,
>>>>>
>>>>>> You tell me please. How has your testing gone for 6.1 so far? Does it
>>>>>> work properly for you? Are you and/or your company willing to test out
>>>>>> the -rc releases and provide feedback if it works or not for your
>>>>>> systems? Do you have problems with 6.1.y vs. older kernels? Is there
>>>>>> anything missing in it that you feel needs to be addressed with a newer
>>>>>> kernel instead?
>>>>>
>>>>> We have been integrating and testing 6.1 on the Microblaze, ARM32 and
>>>>> ARM64-bit architectures over the past few weeks. These builds have
>>>>> been successful and we are able to run our regression tests on hardware
>>>>> targeting our FPGA SoC devices.
>>>>>
>>>>> We're continuing our tests as new updates to the 6.1 kernel series
>>>>> appear.
>>>>
>>>> As Kris said AMD/Xilinx has already moved internal SOC tree to 6.1 based
>>>> kernel in expectation that 6.1 will become next LTS.
>>>> And I am not aware about any issue from testing team related to 6.1 kernel
>>>> version. And we are covering our AMD/Xilinx SOCs based on arm32/arm64 and
>>>> Microblaze CPUs.
>>>>
>>>> It would be good to continue with the same strategy which using the latest
>>>> kernel at that year which is what I am hearing all the time from others that
>>>> 6.1 was last kernel at that year and it should be LTS.
>>>
>>> Generally yes, I pick the last release of the year but we need people to
>>> verify and validate that both it works for them, and that they are going
>>> to be using it in their systems and can provide testing results to us
>>> (as well as providing a way for their devices to actually be updated to
>>> the new releases, we've had previous stable kernel releases that were
>>> never actually shipped out to devices...)
>>
>> We are preparing base (every year) for our customers which is what it is
>> also shipped in our distribution.
>
> What distribution does AMD create? Who uses it? Where is it published
> and how is it updated?
AMD acquired Xilinx last year. That's why Xilinx PetaLinux distribution is under
AMD wings. It means it is distribution for Xilinx SOCs (Microblaze, Zynq
(arm32), ZynqMP/Versal/VersalNET(arm64).
https://www.xilinx.com/products/design-tools/embedded-software/petalinux-sdk.html
It is used initially by all Xilinx customers. Kernel itself is wired inside this
distribution and also used by Xilinx meta Layers in Yocto.
Cannonical is also using it as a base for AMD/Xilinx derivative kernel in Ubuntu
for supporting arm64 based SOCs.
>> Other distribution like Ubuntu with their derivative kernels prefer to stay
>> on the LTS kernels too.
>
> I already discuss this with the various "normal" distributions all the
> time so they know what is going on here already.
ok
>> Also users will be getting fixes against our base for extended period with
>> fixes going from vanilla kernel.
>
> What is "your base"? Who uses this? How long is it supported?
For 2022 it was 5.15 + Xilinx SOC patches.
For 2023 it is going to be 6.1 + Xilinx SOC patches.
As I said above. It is wired in petalinux, yocto and also partners are using it.
Xilinx is supporting this kernel for one year till the next upgrade.
After it 3rd party partners are continue to support these kernels if required.
>
>> For code which is not upstream(which we unfortunately have it) we are
>> providing fixes only till the next LTS version base is created.
>
> So you only support the image for one year?
From AMD/Xilinx point of view unfortunately yes but in Ubuntu via derivative
kernel newer LTS version are merged and supported base on their support strategy.
>> That's why it is very beneficial to use for our base kernel which is going
>> to be LTS that users will get that extended period support.
>
> But you should be keeping this up to date for each normal release,
> right?
We have never had enough resources to support multiple kernels. In perfect world
we should do it but there are all the time constraints.
I am keep pushing over years to do upstreaming as early as possible and then our
changes will be spread to all kernels. But we are not there yet.
> Never do only yearly jumps, that way causes way too much work
> and is proven to be a bad idea.
I know that for many years but not the person who is deciding the upgrade strategy.
>
> And why not just update your "customers" to every normal release? Why
> stick them with one a year? What is preventing more frequent updates?
Questions are correct but I am not defining strategy.
My goal is very simple to push everything to upstream and then we don't need to
have discussions about it.
>> Base Kernel version is taken after your decision about LTS. But this year
>> because of timing we couldn't wait for this decision. That's why 6.1 was
>> taken with expectation that your generic concept about picking up the last
>> release of the year is going to continue.
>
> That's a great guess, but again, you should always be updating your
> out-of-tree changes against every release so it will not matter what
> kernel is picked as a stable one or not.
There are a lot of things what we should be doing but we don't have unlimited
number of resources especially on testing side. For me it is not a problem to
preparing that kernels but someone has to run regressions over it and fixing
issues if any issue happens.
>> Tested wise. We have test result from 6.1 <.0> and I have also shared 6.1.5
>> based version for our distribution. As of today we can't see any issue with
>> 6.1 kernel in general on features which we are using on AMD/Xilinx SOCs.
>
> Great, can you also test the -rc releases to make sure we don't break
> anything for your systems?
Request to test the HEAD of TF-A, U-Boot and Linux was sent long time ago.
And I hope that regressions are running based on available features internally.
And our ZynqMP board is the part of LTSI and KernelCI and I see that regression
is running there properly
https://linux.kernelci.org/soc/zynqmp/job/next/
https://lava.ciplatform.org/scheduler/device_type/zynqmp-zcu102
Another regression is running on Canonical side.
>> Also Jonathan wrote at https://lwn.net/Articles/915435/
>> "Unless something extremely surprising happens, 6.1 will be the final kernel
>> release for 2022, and thus will become the next LTS kernel."
>> That's why I hope that 6.1 is going to be next LTS.
>
> Testing and feedback is going to be what allows this to happen. I can't
> happen in a vacuum, and nor should you want it to.
And that was the purpose of jumping to this thread to send you a message that we
are going to use 6.1 kernel and we can't see any issue with it on our side.
If 6.1 is going to be LTS then good for us.
If different kernel is going to be pick up based on feedback you get then we
will just stay on kernel which is not going to be LTS.
For me this discussion is worth as input for internal discussion for kernel
selection for 2024.
As I said I prefer to push everything upstream, properly mark fixes and then
kernel version decision is up to every distribution/project. I got there with
TF-A project and we are pretty much there with U-Boot and the kernel is the last
one to focus.
>>>> I didn't run any stats but normally also more patches are going to this
>>>> version to be the part of LTS.
>>>
>>> What do you mean by this? The patches accepted so far since 6.1.0 was
>>> released, or up until 6.1.0 was released? For the patches since 6.1.0
>>> was released, that's due to more developers/maintainers tagging patches
>>> during the -rc1 merge window for stable releases (honestly they should
>>> have gotten them into the -final release first), and due to us having
>>> better tools in digging up potential stable patches (i.e. Sasha's
>>> AUTOSEL bot work.)
>>
>> I am just saying that developers/driver owners can simple do calculation to
>> identify LTS version. When they know it they also know time when their
>> deadline is for upstreaming work. It means if patch is accepted between
>> 6.0-r1 and 6.0-rc5/6 they know that it will get to 6.1 merge window.
>
> That is what I am afraid of and if it causes problems I will purposfully
> pick the previous release. This has happened in the past and is never
> an excuse to get anything merged. Code gets merged when it is ready,
> not based on a LTS release.
No doubt about it.
Thanks,
Michal
On Mon, Jan 16, 2023 at 01:16:33PM +0100, Michal Simek wrote:
> > This is probably the best reason not to preannounce when the LTS
> > release will be ahead of time --- because it can be abused by
> > developers who try to get not-ready-for-prime-time features into what
> > they think will be the LTS kernel, with the result that the last
> > release of the year could be utterly unsitable for that perpose.
>
> None is saying that not-ready-for-prime-time feature is pushed.
> In our case all code before upstream goes to soc vendor and it stays there
> for quite a long time when developers have time to upstream it.
> I can imagine that this can happen when you use upstream first solution
> where the code is not fully tested on all configurations.
The problem is that sometimes code meant for a particular SOC could
break other users. The most extreme versions of this was an SOC
kernel that support in for big.little ARM CPU's that created generic
kernel .c files that *would* *not* *compile* on x86. I've seen this
personally, and it impacted the ability for me to implement ext4
encryption for Chrome and Android, in that it worked fine on the
upstream kernel (because *I* develop my featuers upstream first), but
broke when I had to adapt and make chagnes for the SOC kernel that had
changs that had not been pushed upstream.
So if it hasn't been pushed to the upstream kernel, all of the testing
in the world in the SOC kernels doesn't count. Push to upstream
*first*, and *then* backport to the SOC kernel. Better yet, if all of
your device drivers are developed upstream first, then you might not
need that never to be sufficiently @#$?!@? SOC kernel...
> But our customers/users are making products based on code we developed for them.
> That's why I am telling to developers to upstream code whenever it is ready
> to be upstreamed but not everybody is following recommendations . And for
> new SOCs we should be couple of months ahead for any customer that's why it
> shouldn't really matter if that feature goes to one or another kernel.
If people don't listen to you, then they deserve all the pain that
they get, and upstream should not be bending over backwards for them.
And maybe we can try to get mobile device manufacturers to choose not
to chose that SOC when making choices for their next generation
flagship devices....
- Ted
On Sat, Jan 14, 2023 at 3:31 AM Greg KH <[email protected]> wrote:
>
> On Sat, Jan 14, 2023 at 08:14:12AM +0100, Willy Tarreau wrote:
> > On Fri, Jan 13, 2023 at 04:40:19PM -0500, Theodore Ts'o wrote:
> > > On Fri, Jan 13, 2023 at 05:22:56PM +0100, Greg KH wrote:
> > > > > I am just saying that developers/driver owners can simple do calculation to
> > > > > identify LTS version. When they know it they also know time when their
> > > > > deadline is for upstreaming work. It means if patch is accepted between
> > > > > 6.0-r1 and 6.0-rc5/6 they know that it will get to 6.1 merge window.
> > > >
> > > > That is what I am afraid of and if it causes problems I will purposfully
> > > > pick the previous release. This has happened in the past and is never
> > > > an excuse to get anything merged. Code gets merged when it is ready,
> > > > not based on a LTS release.
> > >
> > > This is probably the best reason not to preannounce when the LTS
> > > release will be ahead of time --- because it can be abused by
> > > developers who try to get not-ready-for-prime-time features into what
> > > they think will be the LTS kernel, with the result that the last
> > > release of the year could be utterly unsitable for that perpose.
> >
> > We know this risk exists but since Greg never makes promises on any
> > version, it remains reasonable.
>
> I have to _not_ make promises because in the past when I did, people
> threw crap into the kernel with the "justification" that they had to get
> it in this specific kernel because it was going to be the LTS one.
>
> We can't have nice things, because people abuse it :(
So, is there a final decision taken on what will be our next LTS?
Went through https://kernel.org/category/releases.html but it still shows
v5.15 as the latest LTS version.
Thanks,
Ruslan
On 05/02/2023 06:27, Ruslan Bilovol wrote:
> So, is there a final decision taken on what will be our next LTS?
> Went through https://kernel.org/category/releases.html but it still shows
> v5.15 as the latest LTS version.
No announcement has been made yet on this - my understanding is that a
greater volume and community involvement in testing and feedback is
required to indicate the quality of 6.1 (currently 6.1.12) prior to Greg
making that decision on behalf of the community.
Kris
On Thu, Feb 16, 2023 at 10:41:01AM +0000, Kris Chaplin wrote:
> On 05/02/2023 06:27, Ruslan Bilovol wrote:
>
> > So, is there a final decision taken on what will be our next LTS?
> > Went through https://kernel.org/category/releases.html but it still shows
> > v5.15 as the latest LTS version.
>
> No announcement has been made yet on this - my understanding is that a
> greater volume and community involvement in testing and feedback is required
> to indicate the quality of 6.1 (currently 6.1.12) prior to Greg making that
> decision on behalf of the community.
Have you looked at the above link recently? :)
On 16/02/2023 11:20, Greg KH wrote:
> Have you looked at the above link recently? :)
Oops! Superb.. Thanks Greg.