Can't build 6.6 kernel for x86_64

[Elliott Mitchell]

On Tue, Aug 27, 2024 at 09:08:48PM +0200, Felix Fietkau wrote:
> 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

How?  The approach I'm suggesting appears almost completely orthogonal to
this issue.  I could see the above process making verifying package
builds harder, but doesn't seem to actually break this.

In fact the difference between in-tree module builds versus out-of-tree
module builds is *very* small.  I was very close to being able to build
every package outside the kernel build.  I ran into some difficulty of
the two build types weren't *quite* identical, but hopefully that will be
addressed in the future.

The kernel maintainer I interacted with favored a distinct approach from
what I had, but did seem to acknowledge the processes *should* be
identical.  If that works, then I may have a rather superior approach for
module building for 6.11.

> - make kernel_menuconfig/oldconfig

Why is this so valuable?  Certainly the kernel configuration program is
handy for doing fully-manual kernel configuration.  Yet for OpenWRT I
would expect it to be rather more valuable to keep kernel options one
cares about (CONFIG_NETFILTER=y) from ones which are merely needed to
generate valid kernel configurations (CONFIG_NF_LOG_IPV6=n).

I've run across a number of kernel configuration options which were set
inappropriately (CONFIG_SCx200=y on *all* x86 platforms, not just geode),
so this certainly hasn't kept everything clean.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445