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
- make kernel_menuconfig/oldconfig
- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel