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

From: Julien Olivain <ju.o@free.fr>
To: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH] linux: select BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL when needed
Date: Mon, 30 Dec 2024 19:24:12 +0100	[thread overview]
Message-ID: <1ebf8adf851467fc9965ffdc5949688d@free.fr> (raw)
In-Reply-To: <b58674e6-2aa1-4f27-831a-be9461070242@korsgaard.com>

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