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.dzied...@gmail.com> ha scritto:
sob., 3 lut 2024 o 13:08 Hauke Mehrtens <ha...@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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
