In newer kernel versions (5.8+ ?) there is CONFIG_UNUSED_KSYMS_WHITELIST option which can point to a file filled with a list of KSYMS used by external modules. This mentioned list is rather hard to fill automatically, but it definitely possible. Lets say every external module will store a list of KSYMS they used in a separate files, which can be used than to fill that mentioned list for new installed kernel sources. But this is just suggestion and not the subject of this bug report. I asking for changes like this: CUT---- --- linux-mod.eclass +++ linux-mod.eclass @@ -581,7 +581,7 @@ linux-mod_pkg_setup() { fi # External modules use kernel symbols (bug #591832) - CONFIG_CHECK+=" !TRIM_UNUSED_KSYMS" + [[ -z ${I_KNOW_WHAT_I_AM_DOING} ]] && CONFIG_CHECK+=" !TRIM_UNUSED_KSYMS" linux-info_pkg_setup; require_configured_kernel CUT---- I can confirm I can build and use x11-drivers/nvidia-drivers with TRIM_UNUSED_KSYMS enabled. Reproducible: Always Steps to Reproduce: 1. Set CONFIG_TRIM_UNUSED_KSYMS kernel option. 2. Build kernel. 3. Emerge/Re-emerge x11-drivers/nvidia-drivers (or any other external module). Actual Results: Fail with warning about TRIM_UNUSED_KSYMS enabled. Expected Results: Successful build if everything configured properly. Or sometimes build failing and reporting missing KSYM, which is ok and this KSYM can be added into the CONFIG_UNUSED_KSYMS_WHITELIST list file. Usually happens for major kernel version updates.
Affected packages (inherit linux-mod): app-crypt/tpm-emulator app-emulation/virtualbox-guest-additions app-emulation/virtualbox-modules app-laptop/tp_smapi app-laptop/tuxedo-keyboard dev-util/lttng-modules dev-util/sysdig-kmod media-libs/svgalib media-tv/v4l-dvb-saa716x media-video/v4l2loopback net-dialup/accel-ppp net-firewall/ipset net-firewall/ipt_netflow net-firewall/rtsp-conntrack net-firewall/xtables-addons net-fs/openafs net-misc/AQtion net-misc/dahdi net-misc/ena-driver net-misc/openvswitch net-misc/r8168 net-vpn/wireguard-modules net-wireless/broadcom-sta sci-libs/linux-gpib-modules sys-apps/frandom sys-apps/smc-sum-driver sys-block/rts_pstor sys-cluster/knem sys-cluster/lustre sys-fs/loop-aes sys-fs/vhba sys-fs/zfs-kmod sys-fs/zfs sys-kernel/cryptodev sys-kernel/kpatch sys-power/acpi_call sys-power/bbswitch sys-power/tuxedo-cc-wmi x11-drivers/nvidia-drivers
QA has obsoleted I_KNOW_WHAT_I_AM_DOING . If you can think of a good way of supporting this, please re-open with your thoughts.
In current kernel versions (5.15) CONFIG_TRIM_UNUSED_KSYMS option depends on CONFIG_EXPERT=y, so maybe allow this if expert mode enabled. Could be implicit confirmation similar to "I_KNOW_WHAT_I_AM_DOING". CONFIG_EXPERT dependency may be temporary and could be dropped in future kernel versions, but keeping it in eclass is an alternative to completely restricted kernel option.
I'm thinking about something in config GENTOO_LINUX like: CONFIG_ALLOW_TRIM_UNUSED_KSYMS Then, linux-mod can call: linux_chkconfig_present CONFIG_ALLOW_TRIM_UNUSED_KSYMS which should give you what you need without messing with the kernel's EXPERT which I am not keen to manipulate for our own purposes.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d9687a4df038382187300d6f44230661ff5bc377 commit d9687a4df038382187300d6f44230661ff5bc377 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-05-23 09:25:02 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-05-29 13:03:27 +0000 linux-mod-r1.eclass: new eclass, rewrite of linux-mod.eclass Here's a rough overview of -r0 -> -r1 differences with occasional rationale behind them if felt relevant (for migrating, refer to the eclassdocs instead as this does not really document usage changes): Features that did not exist in previous eclass (not exhaustive): * automatic modules signing support, been often requested and users would instead use messy bashrc hacks to accomplish this (enabled with USE=modules-sign) * modules (manual) stripping support to allow stripping *before* signing and compression (can be disabled with USE=-strip) * can auto-select toolchain to match kernel, e.g. if built with clang-15 then it won't use gcc nor clang-16 if possible (will warn if the matching compiler went missing) * helper functions to profit from the above 3 even if not using linux-mod-r1_src_compile+install (e.g. for zfs-kmod) * generic supported kernel version checks (min/max) which comes with an encouragement to use LTS kernels for out-of-tree modules (but max is not enforced, just makes a strong suggestion) * linux-mod-r1_src_install now does einstalldocs * can guess some common build targets rather than just 'module', largely removing the need for BUILD_TARGETS * user-oriented MODULES_EXTRA_EMAKE among other few variables * various additional sanity checks hopefully making issues clearer for users and ebuilds a bit harder to write wrong "Features" that existed but were not kept (not exhaustive): * support for <kernel-2.6(!) modules, eclass only tested with >=4.14.x * allowing doing all in global scope using variables ran through `eval` (this often led to all sort of variable misuse in global scope) * MODULESD_* support, originally meant to keep but it is used by only 5 packages and holds very little meaning that I can see even in these (when needed, packages should write their own .conf) * moduledb, was being updated for nothing in postinst/postrm despite the tool that can use this (sys-kernel/module-rebuild) being gone from the tree since Feb 2014 * convert_to_m(), only 1 in-tree ebuild uses this right now (svgalib) * various other functions with no consumers were dropped, some were likely meant to be @INTERNAL, get-KERNEL_CC was never used either and now there's ${KERNEL_CC} * running 'clean' by default, this sometime led to race conditions by attempting to clean and build at same time in e.g. nvidia-drivers (if an ebuild truly need this, it can be specified manually) * INSTALL_MOD_PATH support, this integrates badly with ebuilds that use it as DESTDIR with e.g. `make INSTALL_MOD_PATH="${ED}" install` or find "${ED}"/lib/modules, etc... requiring extra consideration (also feels inconsistent with how ebuilds normally work, the few concerned users may be interested by setting ROOT or manually moving files instead -- but support was missing until 2021 so it should have little impact) * BUILD_FIXES support, this is set by linux-info.eclass but has no real relevance that I can see (ebuilds have sometime wrongly used it) * undocumented feature CONFIG_CHECK="@CONFIG:modname" (or so?) meant for automagic based on kernel config is no longer supported, this also removes the also undocumented MODULE_IGNORE used by it (found 0 ebuilds using these in the tree, can be done manually if needed) * converting CONFIG_CHECK to non-fatal for running again on binary merge when (while *possible*) it's rather unlikely would build modules for a different kernel than the one that will be used * having preinst and postrm exports, removed -> originally wanted to remove pkg_setup too but it complicated things with linux-info's own pkg_setup and made the eclass feel less convenient and error-prone with environment handling Dependency changes: * virtual/libelf DEPEND removed, building objtool (which uses this) is not handled by the eclass and does not seem auto-built by make if missing, as such the dependency is not used *here* but rather by dist-kernels and source packages which both already request it. * sys-apps/kmod[tools] BDEPEND+IDEPEND added, and removed from DEPEND (linux-mod-r0 uses it similarly but lacks the eapi7+8 adjustment) * modules-sign? ( dev-libs/openssl virtual/pkgconfig ) BDEPEND for building sign-file, unlike objtool it may need rebuilds for openssl and is handled here * dependencies are no longer guarded by "kernel_linux? ( )", it only served to silence pkgcheck and then give build failures (linux-only ebuilds should be masked on non-Linux profiles or, if mixed, use a masked MODULES_OPTIONAL_IUSE which *can* be kernel_linux). Tentative changes: * drop KERNEL_ABI support, (nowadays) kernel seems to append its own -m32/-m64 and should be no need for multilib.eclass complications (tested to work *at least* with x32[userland]+64bit[kernel]) * ^ but add hppa2.0->64 kgcc64 switching like kernel-build.eclass * drop addpredict wrt bug #653286, assuming no longer relevant given unable to reproduce even with kernel-4.14.315+split-debug+some misc modules, perhaps would with spl but that (removed) ebuild is too broken to try Misc changes: * misc -> extra default install dir, to match the kernel's defaults (this is also where zfs-kmod already installs due to that default) Three bugs were addressed, but not closing given -r0 remains affected: * bug #447352: modules signing is supported * bug #759238: arguably not an issue anymore in -r0 either due to CHECKCONFIG_DONOTHING=1 (bug #862315) now existing, but -r1 additionally makes it non-fatal if a whitelist exists in the kernel * bug #816024: trying to select toolchain better is a -r1 highlight Additionally, becomes WONTFIX in this version: * bug #642240: INSTALL_MOD_PATH support is reverted Bug: https://bugs.gentoo.org/447352 Bug: https://bugs.gentoo.org/642240 Bug: https://bugs.gentoo.org/759238 Bug: https://bugs.gentoo.org/816024 Closes: https://github.com/gentoo/gentoo/pull/31154 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> eclass/linux-mod-r1.eclass | 1206 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1206 insertions(+)
This is addressed in the new linux-mod-r1.eclass
