Can't build 6.6 kernel for x86_64

[Felix Fietkau]

On 27.08.24 19:31, Elliott Mitchell wrote:
> On Thu, Jul 11, 2024 at 08:51:24PM -0600, Philip Prindeville via openwrt-devel wrote:
> 
>> Date: Thu, 11 Jul 2024 20:51:24 -0600
>> From: Philip Prindeville <philipp_subx at redfish-solutions.com>
>> 
>> Was able to get a build with:
>> 
>> --- a/kernel-config
>> +++ b/kernel-config
>> @@ -35,6 +35,8 @@ CONFIG_CHR_DEV_SG=m
>>  CONFIG_CLZ_TAB=y
>>  CONFIG_COREDUMP=y
>>  CONFIG_CRASH_DUMP=y
>> +CONFIG_CRASH_HOTPLUG=y
>> +CONFIG_CRASH_MAX_MEMORY_RANGES=8192
>>  CONFIG_CRYPTO_ABLK_HELPER=y
>>  CONFIG_CRYPTO_AKCIPHER=y
>>  CONFIG_CRYPTO_AKCIPHER2=y
>> @@ -67,6 +69,8 @@ CONFIG_CRYPTO_HW=y
>>  CONFIG_CRYPTO_JITTERENTROPY=y
>>  CONFIG_CRYPTO_KPP=y
>>  CONFIG_CRYPTO_KPP2=y
>> +# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
>> +# CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is not set
>>  CONFIG_CRYPTO_MD5=m
>>  CONFIG_CRYPTO_NULL=y
>>  CONFIG_CRYPTO_POLY1305=y
> 
> What is/are the justification(s) for the current approach to kernel
> configuration handling?
> 
> Every time I take a look I cannot help noticing it requires a *lot* of
> manual intervention.  Worse, since most configuration options need to be
> set, it is hard to distinguish options which are set due to features
> being desired versus those needed to simply get the kernel to build.
> 
> This means many extra options may have leaked in which are no longer
> desireable.  This means kernel updates have to change many options and
> it can be quite non-obvious when unwanted options sneak in.
> 
> 
> I think it might be better to instead do something along the lines of:
> 
> cp target/linux/generic/config-${version} linux-${version}/arch/${ARCH}/configs/generic.config
> cp target/linux/${BOARD}/config-${version} linux-${version}/arch/${ARCH}/configs/${BOARD}.config
> cp target/linux/${BOARD}/${TARGET}/config-${version} linux-${version}/arch/${ARCH}/configs/${BOARD}_${TARGET}.config
> #
> make ARCH=${ARCH} defconfig
> make ARCH=${ARCH} generic.config
> make ARCH=${ARCH} ${BOARD}.config
> make ARCH=${ARCH} ${BOARD}_${TARGET}.config
> 
> Mainly since the time when OpenWRT's kernel configuration system was
> created, the Linux kernel configuration system has grown comparable
> functionality.  This would make OpenWRT's build rather more robust, plus
> emphasize options which were deliberately chosen.

I designed the current kernel configuration handling based on the 
following requirement list (likely incomplete):

- making it as easy as possible to handle dynamic kernel config changes 
for packaging kmod packages
- not enabling kernel modules which are not packaged
- keeping most common kernel config symbols in a generic file which is 
shared across targets and can be used to change options for all targets
- being able to edit the target/subtarget kernel config with 
menuconfig/oldconfig while storing only deltas relative to the generic 
config

What you're proposing seems simple on the surface, but in my opinion 
ignores important parts of the kernel config maintenance, especially:
- package based kernel module selection
- make kernel_menuconfig/oldconfig

- Felix