diff mbox series

[next,1/1] package/linux-backports: bump version to 5.15.58

Message ID 20220813093627.369221-1-ju.o@free.fr
State Superseded
Headers show
Series [next,1/1] package/linux-backports: bump version to 5.15.58 | expand

Commit Message

Julien Olivain Aug. 13, 2022, 9:36 a.m. UTC
This commit also change the minimal supported kernel version from 3.10
to 4.4. See [1].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/tree/README?h=v5.15.58-1#n11

Signed-off-by: Julien Olivain <ju.o@free.fr>
---
Tested with backports defconfig "ath10k" with a kernel 5.4.24.
---
 package/linux-backports/Config.in            | 2 +-
 package/linux-backports/linux-backports.hash | 4 ++--
 package/linux-backports/linux-backports.mk   | 8 ++++----
 3 files changed, 7 insertions(+), 7 deletions(-)

Comments

Thomas Petazzoni Aug. 13, 2022, 10:54 a.m. UTC | #1
Hello Julien,

On Sat, 13 Aug 2022 11:36:27 +0200
Julien Olivain <ju.o@free.fr> wrote:

> This commit also change the minimal supported kernel version from 3.10
> to 4.4. See [1].

Could this be problematic for some of our users? Do we want to keep
support for an older linux-backports release to still support 3.10
kernels?

I can imagine that the people who end up using linux-backports are
probably stuck with an old kernel for some reason, so raising the
minimum kernel version required to use linux-backports is probably
something we should do with a bit of care?

Thomas
Julien Olivain Aug. 13, 2022, 8:01 p.m. UTC | #2
Hi Thomas,

On 13/08/2022 12:54, Thomas Petazzoni wrote:
> Hello Julien,
> 
> On Sat, 13 Aug 2022 11:36:27 +0200
> Julien Olivain <ju.o@free.fr> wrote:
> 
>> This commit also change the minimal supported kernel version from 3.10
>> to 4.4. See [1].
> 
> Could this be problematic for some of our users? Do we want to keep
> support for an older linux-backports release to still support 3.10
> kernels?
> 
> I can imagine that the people who end up using linux-backports are
> probably stuck with an old kernel for some reason, so raising the
> minimum kernel version required to use linux-backports is probably
> something we should do with a bit of care?

I agree that the purpose of linux-backports is to bring new drivers to
old kernels. Then, how old is reasonably old?

Few points:

- v4.4 was released in January 2016. It is no longer maintained (last
   version is v4.4.302 released in February 2022). Oldest still
   maintained LTS is currently 4.9.

- Oldest maintained CIP kernel is currently CIP 4.4. See [1].

- The oldest kernel in Buildroot defconfigs is currently 4.4.7.
   See [2].

- Trying to compile kernel v3.10.108 in qemu_aarch64_virt_defconfig
   did not worked out-of-the-box for me (on Buildroot tag
   2022.08-rc1, in utils/docker-run). Build fails with:

     dtc-lexer.lex.c: In function 'yylex':
     dtc-lexer.l:46:18: error: 'yylloc' undeclared (first use in this 
function); did you mean 'yyalloc'?

I thought it would not be such big issue to update linux-backports and 
raise
its minimal kernel version requirement to 4.4 (which is somewhat the 
oldest
kernel which is still maintained we can get today).

I let you decide what is the oldest kernel version which is supposed
to compile in Buildroot, at a given point in time. Maybe we could add
a test or a defconfig for that version, to make sure it's actually
working.

In the meantime, I suggest we could update linux-backports to the
intermediate version v5.10.110-1 which is the highest version which
does not change the minimal kernel version requirement (which
is >= 3.10).

What do you think?

Best regards,

Julien.

[1] 
https://wiki.linuxfoundation.org/civilinfrastructureplatform/start#kernel_maintainership
[2] 
https://git.busybox.net/buildroot/tree/configs/s6lx9_microboard_defconfig?h=2022.08-rc1#n10
Yann E. MORIN Aug. 14, 2022, 8:23 p.m. UTC | #3
Thomas, Julien, All,

On 2022-08-13 22:01 +0200, Julien Olivain spake thusly:
> On 13/08/2022 12:54, Thomas Petazzoni wrote:
> >On Sat, 13 Aug 2022 11:36:27 +0200
> >Julien Olivain <ju.o@free.fr> wrote:
> >>This commit also change the minimal supported kernel version from 3.10
> >>to 4.4. See [1].
> >Could this be problematic for some of our users? Do we want to keep
> >support for an older linux-backports release to still support 3.10
> >kernels?
> >
> >I can imagine that the people who end up using linux-backports are
> >probably stuck with an old kernel for some reason, so raising the
> >minimum kernel version required to use linux-backports is probably
> >something we should do with a bit of care?

But then, one could argue that this is the same with other packages that
get requirements on newer kernel headers (and thus probably about newer
running kernel). We can't hold back forever.

The alternate solution is not great: we could add a version choice:

    config BR2_PKG_LNX_BACKPORTS_5_15_X
        bool "5.15.x (for kernels back to 4.4)"

    config BR2_PKG_LNX_BACKPORTS_5_8_X
        bool "5.8.x (for kernels back to 3.10)"

But this is not ideal... :-/

> - Trying to compile kernel v3.10.108 in qemu_aarch64_virt_defconfig
>   did not worked out-of-the-box for me (on Buildroot tag
>   2022.08-rc1, in utils/docker-run). Build fails with:
> 
>     dtc-lexer.lex.c: In function 'yylex':
>     dtc-lexer.l:46:18: error: 'yylloc' undeclared (first use in this
> function); did you mean 'yyalloc'?

Gah. This is 9b41b54be077 (linux: fix build with host-gcc 10+)...

That's because in 3.10, the dtc sub-dir still had the pre-generated
lexer and parser. And with 9b41b54be077, we remove all lines that
instanciate yylloc as a YYLTYPE:

    grep -Z -l -r -E '^YYLTYPE yylloc;$$' $(@D) \
    |xargs -0 -r $(SED) '/^YYLTYPE yylloc;$$/d'

So, this will remove it in bot the actual source and the pre-generated C
files.

So, yeah, we might even be able to build a 3.10 kernel with contemporary
Buildroot versions anyway...

We could fix that by passing REGENERATE_PARSERS=1 in LINUX_MAKE_FLAGS...
Julien, could you test that, please?

Regards,
Yann E. MORIN.
Thomas Petazzoni Aug. 15, 2022, 9:39 a.m. UTC | #4
On Sun, 14 Aug 2022 22:23:00 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> But then, one could argue that this is the same with other packages that
> get requirements on newer kernel headers (and thus probably about newer
> running kernel). We can't hold back forever.

True. But even systemd only requires 3.13, which is much older than the
minimum 4.4 kernel that would be required by this linux-backports
update.

> The alternate solution is not great: we could add a version choice:
> 
>     config BR2_PKG_LNX_BACKPORTS_5_15_X
>         bool "5.15.x (for kernels back to 4.4)"
> 
>     config BR2_PKG_LNX_BACKPORTS_5_8_X
>         bool "5.8.x (for kernels back to 3.10)"
> 
> But this is not ideal... :-/

That is the sort of solution that I was thinking of, indeed.

Thomas
Thomas Petazzoni Aug. 15, 2022, 9:51 a.m. UTC | #5
On Sat, 13 Aug 2022 11:36:27 +0200
Julien Olivain <ju.o@free.fr> wrote:

> This commit also change the minimal supported kernel version from 3.10
> to 4.4. See [1].
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/tree/README?h=v5.15.58-1#n11
> 
> Signed-off-by: Julien Olivain <ju.o@free.fr>
> ---
> Tested with backports defconfig "ath10k" with a kernel 5.4.24.
> ---
>  package/linux-backports/Config.in            | 2 +-
>  package/linux-backports/linux-backports.hash | 4 ++--
>  package/linux-backports/linux-backports.mk   | 8 ++++----
>  3 files changed, 7 insertions(+), 7 deletions(-)

After discussing briefly with Yann, I think we would like to have a
version choice, to use either the latest linux-backports that is
compatible with 3.10, or the newest linux-backports (for now compatible
with Linux 4.4+).

Would you be willing to rework your patch with this change?

Thanks a lot!

Thomas
Yann E. MORIN Aug. 15, 2022, 9:52 a.m. UTC | #6
Julien, Thomas, All,

On 2022-08-15 11:39 +0200, Thomas Petazzoni spake thusly:
> On Sun, 14 Aug 2022 22:23:00 +0200
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
[--SNIP--]
> > The alternate solution is not great: we could add a version choice:
[--SNIP--]
> That is the sort of solution that I was thinking of, indeed.

Then OK. We can argue that linux-backports is in the same league as the
kernel, so having a version choice makes sense.

Julien, I've marked this patch as changes-requested, while waiting for a
respin that ads the version choice.

Thanks!

Regards,
Yann E. MORIN.
Julien Olivain Aug. 15, 2022, 8:06 p.m. UTC | #7
Hi Yann, Thomas, All,

On 14/08/2022 22:23, Yann E. MORIN wrote:
> Thomas, Julien, All,
> 
> On 2022-08-13 22:01 +0200, Julien Olivain spake thusly:
[...]
>> - Trying to compile kernel v3.10.108 in qemu_aarch64_virt_defconfig
>>   did not worked out-of-the-box for me (on Buildroot tag
>>   2022.08-rc1, in utils/docker-run). Build fails with:
>> 
>>     dtc-lexer.lex.c: In function 'yylex':
>>     dtc-lexer.l:46:18: error: 'yylloc' undeclared (first use in this
>> function); did you mean 'yyalloc'?
> 
> Gah. This is 9b41b54be077 (linux: fix build with host-gcc 10+)...
> 
> That's because in 3.10, the dtc sub-dir still had the pre-generated
> lexer and parser. And with 9b41b54be077, we remove all lines that
> instanciate yylloc as a YYLTYPE:
> 
>     grep -Z -l -r -E '^YYLTYPE yylloc;$$' $(@D) \
>     |xargs -0 -r $(SED) '/^YYLTYPE yylloc;$$/d'
> 
> So, this will remove it in bot the actual source and the pre-generated 
> C
> files.
> 
> So, yeah, we might even be able to build a 3.10 kernel with 
> contemporary
> Buildroot versions anyway...
> 
> We could fix that by passing REGENERATE_PARSERS=1 in 
> LINUX_MAKE_FLAGS...
> Julien, could you test that, please?

I quickly tried adding REGENERATE_PARSERS=1 in LINUX_MAKE_FLAGS.
It's still failing with:

     dtc-lexer.lex.c: In function 'yylex':
     dtc-lexer.l:46:18: error: 'yylloc' undeclared (first use in this 
function); did you mean 'yyalloc'?
     [...]
     dtc-parser.y: In function 'print_error':
     dtc-parser.y:478:17: error: 'yylloc' undeclared (first use in this 
function); did you mean 'yyalloc'?
     dtc-parser.y:478:17: note: each undeclared identifier is reported 
only once for each function it appears in

I'll investigate later.

In order to test that thoroughly, what is the oldest kernel we would 
like to compile
out-of-the-box in Buildroot?  v3.0?

Best regards,

Julien.
diff mbox series

Patch

diff --git a/package/linux-backports/Config.in b/package/linux-backports/Config.in
index 251d202fd2..b20db67308 100644
--- a/package/linux-backports/Config.in
+++ b/package/linux-backports/Config.in
@@ -9,7 +9,7 @@  config BR2_PACKAGE_LINUX_BACKPORTS
 	  recent kernels, backported to older ones.
 
 	  This version of linux-backports supports kernels starting
-	  from 3.10.
+	  from 4.4.
 
 	  https://backports.wiki.kernel.org
 
diff --git a/package/linux-backports/linux-backports.hash b/package/linux-backports/linux-backports.hash
index 3e103424f5..117b1612b2 100644
--- a/package/linux-backports/linux-backports.hash
+++ b/package/linux-backports/linux-backports.hash
@@ -1,5 +1,5 @@ 
-# From: https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v5.8/sha256sums.asc
-sha256  19b4174d89bf11ee221458e11f1e8dace26558498774b823051156f522d2036b  backports-5.8-1.tar.xz
+# From: https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.15.58/sha256sums.asc
+sha256  a3c2a2b7bbaf8943c65fd72f4e7d7ad5e205aeae28b26c835f9d8afa0f9810bf  backports-5.15.58-1.tar.xz
 # Locally computed
 sha256  fb5a425bd3b3cd6071a3a9aff9909a859e7c1158d54d32e07658398cd67eb6a0  COPYING
 sha256  8e378ab93586eb55135d3bc119cce787f7324f48394777d00c34fa3d0be3303f  LICENSES/exceptions/Linux-syscall-note
diff --git a/package/linux-backports/linux-backports.mk b/package/linux-backports/linux-backports.mk
index 068dcffcc8..b4963d302f 100644
--- a/package/linux-backports/linux-backports.mk
+++ b/package/linux-backports/linux-backports.mk
@@ -4,7 +4,7 @@ 
 #
 ################################################################################
 
-LINUX_BACKPORTS_VERSION_MAJOR = 5.8
+LINUX_BACKPORTS_VERSION_MAJOR = 5.15.58
 LINUX_BACKPORTS_VERSION = $(LINUX_BACKPORTS_VERSION_MAJOR)-1
 LINUX_BACKPORTS_SOURCE = backports-$(LINUX_BACKPORTS_VERSION).tar.xz
 LINUX_BACKPORTS_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/projects/backports/stable/v$(LINUX_BACKPORTS_VERSION_MAJOR)
@@ -94,7 +94,7 @@  $(eval $(kconfig-package))
 # instead.
 #
 # Furthermore, we want to check the kernel version, since linux-backports
-# only supports kernels >= 3.10. To avoid overriding linux-backports'
+# only supports kernels >= 4.4. To avoid overriding linux-backports'
 # KCONFIG_STAMP_DOTCONFIG rule defined in the kconfig-package infra, we
 # use an intermediate stamp-file.
 #
@@ -109,8 +109,8 @@  $(LINUX_BACKPORTS_DIR)/.stamp_check_kernel_version: $$(LINUX_DIR)/$$(LINUX_KCONF
 	$(Q)KVER=$(LINUX_VERSION_PROBED); \
 	KVER_MAJOR=`echo $${KVER} | sed 's/^\([0-9]*\)\..*/\1/'`; \
 	KVER_MINOR=`echo $${KVER} | sed 's/^[0-9]*\.\([0-9]*\).*/\1/'`; \
-	if [ $${KVER_MAJOR} -lt 3 -o \( $${KVER_MAJOR} -eq 3 -a $${KVER_MINOR} -lt 10 \) ]; then \
-		printf "Linux version '%s' is too old for linux-backports (needs 3.10 or later)\n" \
+	if [ $${KVER_MAJOR} -lt 4 -o \( $${KVER_MAJOR} -eq 4 -a $${KVER_MINOR} -lt 4 \) ]; then \
+		printf "Linux version '%s' is too old for linux-backports (needs 4.4 or later)\n" \
 			"$${KVER}"; \
 		exit 1; \
 	fi