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_s...@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+sig...@m5p.com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
