[Buildroot] [PATCH] linux: select BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL when needed

[Buildroot] [PATCH] linux: select BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL when needed

[Thomas Petazzoni via buildroot]

The autobuilders are regularly reporting issues when building the
Linux kernel due to BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL not being
enabled.

Since the autobuilders are always using
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG, let's have this option
select BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL when the latest kernel is
used.

For now, we enable this for ARC, Sparc and x86-64, but it might have
to be extended for additional architectures based on build results.

Fixes:

  http://autobuild.buildroot.net/results/596699ede6e651163a23fa50386d84aca24c9a28
  http://autobuild.buildroot.net/results/77a767bcd78f9ed21668cc268e91a4584a821661
  http://autobuild.buildroot.net/results/e846d13c9f001b76a08ffb94f69c8dd26b4f5811

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
 linux/Config.in | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/linux/Config.in b/linux/Config.in
index be44c00d7d..50f1e31427 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -168,6 +168,12 @@ config BR2_LINUX_KERNEL_USE_DEFCONFIG
 
 config BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG
 	bool "Use the architecture default configuration"
+	# We know that the default configuration on some architectures
+	# requires host-openssl, so select it for the latest kernel
+	# version. This is mainly needed to fix autobuilder testing.
+	select BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL if \
+	       BR2_LINUX_KERNEL_LATEST_VERSION && \
+	       (BR2_arcle || BR2_arceb || BR2_sparc || BR2_x86_64)
 	help
 	  This option will use the default configuration for the
 	  selected architecture. I.e, it is equivalent to running
-- 
2.47.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] linux: select BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL when needed

[Julien Olivain]

Hi Thomas,

On 29/12/2024 10:33, Thomas Petazzoni via buildroot wrote:
> The autobuilders are regularly reporting issues when building the
> Linux kernel due to BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL not being
> enabled.
> 
> Since the autobuilders are always using
> BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG, let's have this option
> select BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL when the latest kernel is
> used.
> 
> For now, we enable this for ARC, Sparc and x86-64, but it might have
> to be extended for additional architectures based on build results.
> 
> Fixes:
> 
>   
> http://autobuild.buildroot.net/results/596699ede6e651163a23fa50386d84aca24c9a28
>   
> http://autobuild.buildroot.net/results/77a767bcd78f9ed21668cc268e91a4584a821661
>   
> http://autobuild.buildroot.net/results/e846d13c9f001b76a08ffb94f69c8dd26b4f5811
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> ---
>  linux/Config.in | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/linux/Config.in b/linux/Config.in
> index be44c00d7d..50f1e31427 100644
> --- a/linux/Config.in
> +++ b/linux/Config.in
> @@ -168,6 +168,12 @@ config BR2_LINUX_KERNEL_USE_DEFCONFIG
> 
>  config BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG
>  	bool "Use the architecture default configuration"
> +	# We know that the default configuration on some architectures
> +	# requires host-openssl, so select it for the latest kernel
> +	# version. This is mainly needed to fix autobuilder testing.
> +	select BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL if \
> +	       BR2_LINUX_KERNEL_LATEST_VERSION && \
> +	       (BR2_arcle || BR2_arceb || BR2_sparc || BR2_x86_64)

While reviewing, I quickly tested with:

     cat <<EOF >.config
     BR2_x86_64=y
     BR2_LINUX_KERNEL=y
     BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
     BR2_TOOLCHAIN_EXTERNAL=y
     EOF
     make olddefconfig
     make

It failed with output:

     In file included from 
/buildroot/output/build/linux-6.12.5/tools/objtool/include/objtool/objtool.h:13,
                      from weak.c:10:
     
/buildroot/output/build/linux-6.12.5/tools/objtool/include/objtool/elf.h:10:10: 
fatal error: gelf.h: No such file or directory

This hints to a missing BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF=y.

Do you think we will need the same logic for other
BR2_LINUX_KERNEL_NEEDS_HOST_* configs? It is likely that autobuilder
will catch this kind of failures.

I was wondering if this logic will not become a bit complicated over
time (e.g. BR2_LINUX_KERNEL_NEEDS_HOST_PYTHON3 for aarch64, ...).
What do you think?

If you think this is OK, I'll apply this patch as is and we'll
update those conditions in future commits, when needed.

Best regards,

Julien.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] linux: select BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL when needed

[Thomas Petazzoni via buildroot]

Hello Julien,

+Peter in Cc.

On Sun, 29 Dec 2024 15:41:52 +0100
Julien Olivain <ju.o@free.fr> wrote:

> While reviewing, I quickly tested with:
> 
>      cat <<EOF >.config
>      BR2_x86_64=y
>      BR2_LINUX_KERNEL=y
>      BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
>      BR2_TOOLCHAIN_EXTERNAL=y
>      EOF
>      make olddefconfig
>      make
> 
> It failed with output:
> 
>      In file included from 
> /buildroot/output/build/linux-6.12.5/tools/objtool/include/objtool/objtool.h:13,
>                       from weak.c:10:
>      
> /buildroot/output/build/linux-6.12.5/tools/objtool/include/objtool/elf.h:10:10: 
> fatal error: gelf.h: No such file or directory
> 
> This hints to a missing BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF=y.

Indeed.

> Do you think we will need the same logic for other
> BR2_LINUX_KERNEL_NEEDS_HOST_* configs? It is likely that autobuilder
> will catch this kind of failures.

Yes that would be the idea.

> I was wondering if this logic will not become a bit complicated over
> time (e.g. BR2_LINUX_KERNEL_NEEDS_HOST_PYTHON3 for aarch64, ...).
> What do you think?
> 
> If you think this is OK, I'll apply this patch as is and we'll
> update those conditions in future commits, when needed.

I am not sure myself what is the right solution here. I'm trying to
avoid recurring autobuilder failures. I discussed this topic some time
ago with Peter. My idea was to do tweaks in utils/genrandconfig, but
Peter was on the opinion that we should deal with those issues directly
in the linux package, so that it doesn't just benefit the autobuilders,
but also our users.

Clearly, it's going to be a cat-and-mouse game: we discover issues in
the autobuilders and address them. This is for example the case for the
x86-64 situation you reported. But for example, I only took care of the
"latest kernel version" case, but we might have similar issues for the
CIP versions as well. My idea was to simply deal with those
progressively, improving the logic as we discover new cases.

Note that I am not 100% sure of what the best approach is. Maybe it's
one of those cases where we simply to try one approach, and decide
later if it was the right approach or not?

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] linux: select BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL when needed

[Peter Korsgaard]

On 12/29/24 21:03, Thomas Petazzoni wrote:

> I am not sure myself what is the right solution here. I'm trying to
> avoid recurring autobuilder failures. I discussed this topic some time
> ago with Peter. My idea was to do tweaks in utils/genrandconfig, but
> Peter was on the opinion that we should deal with those issues directly
> in the linux package, so that it doesn't just benefit the autobuilders,
> but also our users.
> 
> Clearly, it's going to be a cat-and-mouse game: we discover issues in
> the autobuilders and address them. This is for example the case for the
> x86-64 situation you reported. But for example, I only took care of the
> "latest kernel version" case, but we might have similar issues for the
> CIP versions as well. My idea was to simply deal with those
> progressively, improving the logic as we discover new cases.
> 
> Note that I am not 100% sure of what the best approach is. Maybe it's
> one of those cases where we simply to try one approach, and decide
> later if it was the right approach or not?

Yes, I think the complexity is more or less the same (+/- differences in 
kconfig vs python) no matter where we put it, so having it in kconfig 
and helping everyone rather than just the autobuilders IMHO makes most 
sense.

But lets see how complicated it turns out over time.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] linux: select BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL when needed

[Julien Olivain]

Hi Peter, Thomas,

On 30/12/2024 13:43, Peter Korsgaard wrote:
> On 12/29/24 21:03, Thomas Petazzoni wrote:
> 
>> I am not sure myself what is the right solution here. I'm trying to
>> avoid recurring autobuilder failures. I discussed this topic some time
>> ago with Peter. My idea was to do tweaks in utils/genrandconfig, but
>> Peter was on the opinion that we should deal with those issues 
>> directly
>> in the linux package, so that it doesn't just benefit the 
>> autobuilders,
>> but also our users.
>> 
>> Clearly, it's going to be a cat-and-mouse game: we discover issues in
>> the autobuilders and address them. This is for example the case for 
>> the
>> x86-64 situation you reported. But for example, I only took care of 
>> the
>> "latest kernel version" case, but we might have similar issues for the
>> CIP versions as well. My idea was to simply deal with those
>> progressively, improving the logic as we discover new cases.
>> 
>> Note that I am not 100% sure of what the best approach is. Maybe it's
>> one of those cases where we simply to try one approach, and decide
>> later if it was the right approach or not?
> 
> Yes, I think the complexity is more or less the same (+/- differences 
> in kconfig vs python) no matter where we put it, so having it in 
> kconfig and helping everyone rather than just the autobuilders IMHO 
> makes most sense.
> 
> But lets see how complicated it turns out over time.

Thanks for the clarifications.

I applied the patch to master.

In the future, if those conditions become too complex, we could still 
adopt
the same strategy as for  the _ARCH_SUPPORTS (i.e. moving the complex
conditions in hidden Kconfig symbols). This should keep the symbol
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG readable.

Best regards,

Julien.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot