Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?

Dave Taht dave.taht at gmail.com
Mon Feb 5 04:09:45 PST 2024


I do not care one whit about CIP. It will lead to redhat-style
ossification and even further delusional consideration that Linux is
"done". The Linux foundation keeps losing its way. I would prefer
OpenWrt (and arm development in particular) continue to track the
newest kernels possible and indeed, somehow, push back into the
mainline kernel processes for older, embedded gear more than it has,
continuing to shrink needed bits as they come up.

As an example, 6.7 had had extensive profiling in it, which made the
tcp stack on AMD in particular more highly performant. But no work was
done that I know of to verify that ARM was not hurt, particularly arm
on older gear - but due to those patches being so beneficial, it looks
like ubuntu plans to ship 6.8 in april. Improvements to the tcp stack
are not openwrt´s primary use case, but being able to stay on top of
linux developments on arm gear is.

Perhaps rather than chasing LF unnecessarily, following a mainstream
distro more closely aligned with ARM might help.

As for 6.1 vs 6.6, having tooling, processing, people, and attitude in
place towards being always being able to go in 4 months to a new
kernel - of any sort - would be a win.

On Mon, Feb 5, 2024 at 5:38 AM Zoltan HERPAI <wigyori at uid0.hu> wrote:
>
> On Sat, 3 Feb 2024, Enrico Mioso wrote:
>
> > On Sat, Feb 03, 2024 at 07:02:44PM +0100, Christian Marangi (Ansuel) wrote:
> >> Il giorno sab 3 feb 2024 alle ore 18:55 Janusz Dziedzic
> >> <janusz.dziedzic at gmail.com> ha scritto:
> >>>
> >>> sob., 3 lut 2024 o 13:08 Hauke Mehrtens <hauke at hauke-m.de> napisał(a):
> >>>>
> >>>> Hi,
> >>>>
> >>>> I track the status of the Linux kernel 6.1 migration in this github
> >>>> issue: https://github.com/openwrt/openwrt/issues/14546
> >>>>
> >>>> There are still many targets on kernel 5.15 without testing support for
> >>>> kernel 6.1 in OpenWrt master. I assume that we need at least 4 months to
> >>>> get everything to 6.1 and more or less stable. Kernel 6.1 support is
> >>>> also missing for some important targets like lantiq, realtek and ramips.
> >>>>
> >>>>
> >>>> Which kernel should we use for the next major OpenWrt release?
> >>>> We have two options and I would like to get some feedback on these:
> >>>>
> >>>> 1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or
> >>>> most of the targets are on kernel 6.1 by default.
> >>>> 2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or
> >>>> most of the targets are on kernel 6.6 by default. Do not do any stable
> >>>> OpenWrt release which supports kernel 6.1.
> >>>>
> >>>> Doing a OpenWrt release with multiple kernels cases too much maintenance
> >>>> effort from my point of view based on previews experience.
> >>>>
> >>>>
> >>>> I think with kernel 6.1 we can branch off at around May 2024. With
> >>>> kernel 6.6 we could probably branch off around September 2024. The final
> >>>> release will be out about 2 to 4 months later.
> >>>>
> >>>> Currently OpenWrt releases are about 1.5 years behind the Linux LTS
> >>>> releases. When we use kernel 6.1 for the next release we will continue
> >>>> to stay 1.5 years behind. When we switch to kernel 6.6 and do not do any
> >>>> release with kernel 6.1 we will probably only stay 10 months behind
> >>>> Linux LTS kernels.
> >>>>
> >>>> There is already a PR requiring kernel 6.6:
> >>>> https://github.com/openwrt/openwrt/pull/14357
> >>>>
> >>>>
> >>>> Currently I would prefer to use kernel 6.6 to get closer to the recent
> >>>> Linux LTS releases.
> >>>>
> >>>
> >>> 6.6 for sure if possible.
> >>>
> >>> Just curious - any reason to not support both or even 5.15? And target
> >>> could decide about it in mk?
> >>> Eg. newest ATH/QCA that base a lot on newest kernel and backports just
> >>> could choose it?
> >>> For older one we already have work done - so just change generic
> >>> patches directory into generic-kernel_ver?
> >>> Or this is more work and problems?
> >>>
> >>
> >> We usually try to stick to a common kernel across all target for stable release
> >> for consistency and to prevent and handle regression in the generic target.
> >>
> >> Also it's really a way to force target on getting updated... If it
> >> wasn't for this
> >> reason we would probably have stuff stuck at 4.19.
> >>
> > Hello all,
> >
> > I would choose 6.1: to get more time for some things to stabilize out and because I am under the impression the kernel size is growing too fast and so we are accelerating hw obsolescence.
> > The 6.1 kernel has also been choosen by the Civil Infrastructure Platform, so it would get some attention and maintenance still.
> >
> > However, my preference / decision is for 6.6 in the end: especially after having felt the pain of developers who need to backport lots of stuff and for which the challenge becomes harder over time.
> > If we need more developers, making development less annoying is preferrable.
> > That said, it would be nice to enable only the needed kernel features for a subtarget, just to incrase efficiency in general.
>
> Hi,
>
> I'm kind of biased here too. 6.1 due to CIP and vendors starting to pick
> 6.1 as their kernel of choice in SDKs, but 6.6 for moving with the
> targets and new stuff we're working on forward.
>
> One thing I fully agree with Hauke is that we should pick one (and only
> one) kernel for the next release, whenever that is. If we need to drop
> targets to achieve it (no maintainer stepping up or lack of storage on
> the devices), so be it.
>
> Also:
>   - riscv targets I'm working on are usually better off with 6.6,
>   - we are unable to keep up with a standard release cycle anyway, so no
> one will tell us off if we delay a release by a few months.
>
> Regards,
> -w-_______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos



More information about the openwrt-devel mailing list