On Sun, 2025-02-09 at 18:27 -0500, Bruce Ashfield wrote:
>
>
> On Sun, Feb 9, 2025 at 5:58 PM Adrian Freihofer
> <adrian.freiho...@gmail.com> wrote:
> > Hi Bruce
> >
> > Am Do., 30. Jan. 2025 um 15:48 Uhr schrieb Bruce Ashfield via
> > lists.openembedded.org
> > <bruce.ashfield=gmail....@lists.openembedded.org>:
> > >
> > >
> > > On Thu, Jan 30, 2025 at 9:31 AM Steve Sakoman via
> > > lists.openembedded.org <steve=sakoman....@lists.openembedded.org>
> > > 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).
I took some time today to understand what you are describing here in
the linux-yocto git repository. Your pointers have helped me to start
my git tool with sensible parameters, so I now understand exactly what
the difference is between linux-yocto and linux-stable.
I agree that the way the linux-yocto git repository is maintained is
the best approach for maintaining a downstream kernel repo. It's at
least as transparent as it can be if you know how to look at the
overwhelming number of branches and merge commits. Basically, it's
about creating a new branch for each major upstream release. Then all
downstream patches are rebased and applied to the new branch of the new
major release. Finally, the branch is maintained by merging the minor
upstream updates into the downstream release branch. Since the merging
of minor updates can probably be automated to a large extent, it should
be possible to follow the stable git repo quickly. And yes, the two
repos were at the same commit when I compared them.
At least from that point of view, it would be possible to run the CVE
checker with ${AUTOREV} for the linux-yocto kernel and get the same
results as if the linux-stable tree would be used. It's not the linux-
yocto git repository which adds the delay it's just the recipe which is
not updated in "real-time" which is also understandable.
>
> >
> > 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.
Yes, got it!
>
> >
> > 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).
Yes, the standard recipe tools should work as for any other recipe. The
magic is how the linux-yocto git repo is maintained and that's a
special non standard tool topic. I see.
>
> 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.
Got it. linux-yocto is in sync with linux-stable.
Thank you!
Adrian
>
> 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 (#211122):
https://lists.openembedded.org/g/openembedded-core/message/211122
Mute This Topic: https://lists.openembedded.org/mt/110897884/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
