staging/hauke/include/kernel.mk, branch v23.05.1

kernel: fix KernelPackage when all KCONFIG are versioned

2023-07-08T13:43:59Z

If a kernel package was defined where all KCONFIG symbols were dynamic, and versioned, no FILES would be installed, as the foreach evaluation was providing the value of the variable defined by the KCONFIG symbol name including the version test Fix this by calling the version_filter function on the list of KCONFIG variable names run through by foreach Example, kernel 6.1: KCONFIG:=CONFIG_OLD@lt6.1 CONFIG_NEW@ge6.1 filter-out any KCONFIG settings forced by package: CONFIG_OLD@lt6.1 CONFIG_NEW@ge6.1 there are dynamic settings, so for each of them, get the value of the make variable defined by symbol name: CONFIG_OLD@lt6.1 is not set CONFIG_NEW@ge6.1 is not set versus CONFIG_OLD is not set CONFIG_NEW=m test if any of these are m, or y if yes, install files, otherwise, nothing to install Signed-off-by: John Thomson (cherry picked from commit b3448b3fdb59d25dce05991dc8f322c1020b090b)

generic: groundwork for RISC-V

2023-06-14T07:22:08Z

Add build infrastructure for RISC-V. Signed-off-by: Zoltan HERPAI (cherry picked from commit 50c05f6cd721130701cbbc77a75d2e090259c4e5)

kernel: Make KERNEL_MAKEOPTS recursively expanded

2022-12-17T19:12:31Z

KERNEL_MAKEOPTS will get expanded when it is used and not when it is defined in the kernel.mk file now. This fixes problems finding dependent kernel modules when it is used by a kernel module package. Without this change the build of packages which depend on other out of tree modules failed when they used KERNEL_MAKE because some symbols could not be found. This happened because KERNEL_MAKE_FLAGS which contains a "if $(__package_mk)" was evaluated where KERNEL_MAKEOPTS was defined and not when the KERNEL_MAKE was used. For packages which included kernel.mk before package.mk we saw this problem. One workaround was to use the correct include order and the other one was to not use KERNEL_MAKE_FLAGS, but copy its content. Signed-off-by: Hauke Mehrtens

kernel: disable stack validation for external module builds as needed

2022-10-20T07:53:23Z

c3e31b6a9b04 and 5f8e5872406d disable stack validation when the build host is not running Linux, as the objtool kernel build tool required for stack validation is not portable to other build host environments. This was achieved by setting CONFIG_STACK_VALIDATION= in KERNEL_MAKEOPTS, and by setting SKIP_STACK_VALIDATION=1 in the environment. KERNEL_MAKEOPTS only has effect for the kernel build, not for external module builds, but through kernel 5.14, SKIP_STACK_VALIDATION worked to disable this feature too, so stack validation was disabled for external module builds as well. Since kernel 0d989ac2c90b, the kernel build no longer considers SKIP_STACK_VALIDATION, so the feature will be disabled for the kernel build, but not for external module builds. When building OpenWrt on a non-Linux build host targeting x86 (the only target architecture for which OpenWrt enables the kernel CONFIG_STACK_VALIDATION) and using kernel 5.15 (such as via CONFIG_TESTING_KERNEL), this caused a build failure during any external module build, such as kmod-button-hotplug. This manifested as build errors such as: make[4]: *** No rule to make target '.../build_dir/target-x86_64_musl/linux-x86_64/button-hotplug/button-hotplug.o', needed by '.../build_dir/target-x86_64_musl/linux-x86_64/button-hotplug/button-hotplug.mod'. Stop. Although button-hotplug.c was present, the implicit rule to make $(obj)/%.o from $(src)/%.c in the kernel's scripts/Makefile.build could not be satisfied in this case, as it also depends on $(objtool_dep), non-empty as a result of the failure to propagate disabling of stack validation to external module builds, in a configuration where it is not possible to build objtool. KERNEL_MAKEOPTS is used for just the kernel build itself, while KERNEL_MAKE_FLAGS is used for both the kernel build and for external module builds. This restores the ability to build OpenWrt in such configurations by moving the CONFIG_STACK_VALIDATION= make argument from KERNEL_MAKEOPTS to KERNEL_MAKE_FLAGS where it is able to affect external module builds properly. Note that the kernel's objtool and related configuration have seen a major overhaul since kernel 5.15, and may need more attention again after 22922deae13f, in kernel 5.19. Signed-off-by: Mark Mentovai

kernel: filter -no-plt from KCFLAGS

2022-06-21T15:41:17Z

Compiler option -no-plt will break kernel builds on some architectures eg. (x86) Filter this option from the recently introduced handling of KCFLAGS vs EXTRA_OPTIMISATION Fixes: 1d42af720c6b ("kernel: use KCFLAGS for passing EXTRA_OPTIMIZATION flags") Suggested-by: Felix Fietkau Signed-off-by: Kevin Darbyshire-Bryant

kernel: support setting extra CFLAGS for kernel compilation

2022-06-20T20:17:38Z

They may be used e.g. to optimize kernel size or performance. Signed-off-by: Rafał Miłecki

kernel: use KCFLAGS for passing EXTRA_OPTIMIZATION flags

2022-06-19T21:23:18Z

This uses kernel's generic variable and doesn't require patching it with a custom Makefile change. It's expected *not* to change any behaviour. Signed-off-by: Rafał Miłecki

build: use KBUILD_HOSTLDFLAGS

2022-05-18T10:32:06Z

According to the GNU make manual, specifying library paths should be done in LDFLAGS rather than LDLIBS. Replace KBUILD_HOSTLDLIBS with KBUILD_HOSTLDFLAGS to pass the host lib directory. Signed-off-by: Stijn Tintel

build: drop HOST_LOADLIBES

2022-05-18T10:32:06Z

HOST_LOADLIBES was renamed to KBUILD_HOSTLDLIBS in kernel 4.19. As the oldest kernel version we support is 5.10, cleanup HOST_LOADLIBES use. Signed-off-by: Stijn Tintel

build: use -nostdinc and -isystem in NOSTDINC_FLAGS for out-of-tree kernel modules

2021-03-18T09:53:26Z

This resolves issues uncovered by musl updates Signed-off-by: Felix Fietkau