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

Zoltan HERPAI wigyori at
Mon Feb 5 02:35:27 PST 2024

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> ha scritto:
>>> sob., 3 lut 2024 o 13:08 Hauke Mehrtens <hauke at> napisał(a):
>>>> Hi,
>>>> I track the status of the Linux kernel 6.1 migration in this github
>>>> issue:
>>>> 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:
>>>> 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.


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.

  - 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.


More information about the openwrt-devel mailing list