On Sun, Feb 9, 2025 at 5:58 PM Adrian Freihofer <[email protected]> wrote:
> Hi Bruce > > Am Do., 30. Jan. 2025 um 15:48 Uhr schrieb Bruce Ashfield via > lists.openembedded.org <[email protected]>: > >> >> >> On Thu, Jan 30, 2025 at 9:31 AM Steve Sakoman via lists.openembedded.org >> <[email protected]> wrote: >> >>> As you may be aware, the support period for Linux kernel LTS releases >>> has changed to two years. This presents a challenge for our Yocto LTS >>> releases, which have 4 year support periods. >>> >>> In light of this, Richard sent an email to the Yocto architecture list >>> in January of 2024 outlining the project's plans for kernel support in >>> future LTS releases (copied below) >>> >>> TLDR: Around the midpoint of the Yocto Scarthgap LTS lifecycle we will >>> backport the then current LTS kernel version and make it the default >>> kernel version. The linux-libc-headers version would remain at the >>> released version. >>> >>> At a recent Yocto Project Technical Team Meeting there was some >>> discussion around the growing kernel CVE counts in the stable >>> branches: >>> >>> kirkstone: 552 >>> scarthgap: 225 >>> >>> >> I hope these aren't based on the fact that I haven't sent the -stable >> updates to the list yet. I do the older branches on a monthly >> cadence, but can increase it. I have all active upstream kernels >> on their latest -stable in linux-yocto already. >> > > Given the increasing importance of timely security updates and the rising > frequency of new CVEs, staying as close as possible to the latest upstream > kernels from kernel.org is becoming more essential than it was a few > years ago. > Additionally, patchsets such as preempt-RT, which were conveniently > offered by > the linux-yocto kernel, are now mainline. > We are creeping away from the question that Steve was asking, not that these aren't valid things to ponder, but they have been thought about many times and are revisited periodically .. that being said, I'll offer some context below. If you take an extremely narrow view of what we do with linux-yocto, then sure (I won't repeat things here, since I've done no less than three presentations on this in the past). Not to mention there are still parts of -rt that are not mainline, and early access BSPs, as well as SDKs that are part of linux-yocto, kept on their own branches so as to not inflict themselves on all users. linux-yocto has almost no delta from upstream timing wise when it is available, and it isn't like we'd be doing a rolling release, the only lag is our own embedded specific testing and validation. So there's nothing to be gained on that front. I only asked that question to be sure that it wasn't related to that (and it wasn't). > > This raises the question: Is a downstream linux-yocto kernel git > repository still > needed? From my naive user's perspective, it would be simpler and more > transparent > if the kernel were handled like any other recipe. Instead of a linux-yocto > recipe > referring to a downstream git repository, there should be a linux and/or a > linux-stable > recipe referring to the corresponding git repositories from kernel.org. > Again, I'd refer to the various previous works on what we do with linux-yocto, and we want fewer, not more reference kernels so we can have the momentum around specific versions. (i.e. there would be no advantage to splitting out -stable) linux-yocto is bit for bit the same as upstream in the /base branches exactly where it is fetched is the only difference. > Ideally also the workflows for updating the kernel and testing the kernel > would > be possible with the Yocto standard workflows like devtool update and > running > oe-selftest. > That's already possible now, but how we use linux-yocto as a collection point for contributions, BSPs, managing the versions, the workflow, etc don't scale to slinging around directories full of patches (again, covered in the various presentations). We heavily test linux-yocto, so obviously oe-*test works, and you don't chuck out a workflow that has scaled and worked for 15 years (and predates devtool significantly if devtool doesn't work (I have no idea, I don't use it and probably never will, but if it is important to folks, I can dive in and fix what is broken (I just need to know what is broken). Back to Steve's question, and one of the other follow ups. We use linux-yocto as a point of momentum for versions, fixes, releases, etc. It always has been and always will be opt-in for people's distros and projects, so they are free to ignore it, or use it. Bruce > > Thank you and regards, > Adrian > >> >> >>> For comparison the master branch CVE count for the kernel is 18 >>> >>> The suggestion was made that we do this kernel version update sooner >>> rather than later, and also include the Kirkstone LTS branch in order >>> to deal with its large number of CVEs. The original plan was to only >>> do this version bump for Scarthgap, so this would be a change to the >>> plan of record. >>> >> >> I don't think we should be updating kirstone to a new kernel while the >> upstream kernel's are active. Both 5.15 and 5.10 are still active on >> kernel.org and I'm still updating them, or am I missing something ? >> >> That was the primary trigger around the updates: EOL on k.org >> >> If we are now questioning the -stable process on k.org that it can't >> keep up on these still active LTS kernels, that is a different question. >> >> If we are questioning it, I have other suggestions around the >> reference kernel versions. >> >> But in the end, as long as the kernel we jump to is actively maintained >> in our newer releases, there's not a lot of extra work so it is fine >> with me. I just want to understand why we'd move kirkstone as well. >> >> Cheers, >> >> Bruce >> >> >>> >>> Please consider the above and respond to this email with any thoughts >>> or concerns you may have about implementing this version bump in both >>> LTS branches in the coming weeks. >>> >>> Thanks! >>> >>> Steve >>> >>> >>> Full text of Richard's email: >>> >>> The project is aware that the kernel versions that ship in our next LTS >>> in April will likely not have support for the full lifetime of our LTS >>> (four years). We've been asked a few questions about this so we wanted >>> to write down what our plan is. >>> >>> Our intent is to support the versions we ship with for as long as is >>> practical. If they become end of life around the mid point of the LTS >>> as expected, our plan is to backport a current LTS kernel at that time >>> into the release and make it the default, leaving the older recipes >>> there for anyone who still needs to use them. It would be based on the >>> kernel in one of our future releases, as appropriate. >>> >>> The linux-libc-headers version would remain at the released version. >>> This is used to control the features in the toolchain/userspace and >>> there is no need to upgrade this to work with a newer kernel version. >>> Upgrading it would potentially change the toolchain and userspace >>> functionality and this is not desirable in the LTS. To be clear, this >>> does mean bleeding edge features in the newer kernel may not be >>> available but that is desirable in the context of the purpose of the >>> LTS. >>> >>> The only reason the headers version would change would be to address a >>> security issue in the toolchain or kernel/userspace interface. >>> >>> Since we don't know what the upstream kernel will do, or when exactly, >>> it is hard to make a definitive plan beyond this. >>> >>> We appreciate this isn't our usual policy of "no upgrades", however if >>> everyone knows this is the plan from the start, we believe that is >>> different and everyone can plan accordingly, hence wanting to make this >>> clear now. >>> >>> Since the project is planning to execute the full QA process against >>> this new version, it is putting a plan in place to switch from the >>> start and it plans not to test against any other version beyond that >>> point, it makes most sense to directly integrate the changes rather >>> than the mix in layer approach which is there for unplanned changes. >>> >>> To be clear, we may also update this plan if/as things develop in the >>> other dependent ecosystems such as kernel as we can't know what will >>> happen in these on the timescales involved. >>> >>> Cheers, >>> >>> Richard >>> (on behalf of the Yocto Project TSC, LTS and kernel maintainers) >>> >>> >>> >>> >> >> -- >> - Thou shalt not follow the NULL pointer, for chaos and madness await >> thee at its end >> - "Use the force Harry" - Gandalf, Star Trek II >> >> >> >> >> -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#211055): https://lists.openembedded.org/g/openembedded-core/message/211055 Mute This Topic: https://lists.openembedded.org/mt/110897884/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
