Update notes for ML:
Likely final as far as initial merge goes.
Given been suggested that it'd be easier to have it in the tree for
testing and that without consumers it can't break anything (yet),
planning to merge tomorrow. Just posting update here as a formality.
I assume the two global USE are okay at this point.
Rough updates overview since v1 after self-review:
- adjust compiler mismatch warning for better visiblity and accuracy
- prevent passing -Werror even if CONFIG_WERROR=y which recent kernels
enable by default (unrealistic for not-frequently-updated modules),
the other -Werror=specific are left alone
- add DEPMOD=: and no-auto-sign/compress CONFIG_ to default makeargs,
this should help streamline ebuilds using make install (zfs-kmod,
dahdi, maybe others), technically useless arguments for others but
should not be harmful
- drop INSTALL_MOD_PATH support, formerly added to mimic -r0 but upon
further reflection I think this is bad and becomes easily inconsistent
when ebuilds use emake install, find commands, and such (getting it
right in zfs-kmod was also confusing)
- drop modules_makeargs_to_array and replace by MODULES_MAKEARGS,
sounded like a good idea at first but this just added extra churn
- various typos, wording, and style adjustments/fix
----------------------
Normal commit summary:
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
Signed-off-by: Ionen Wolkens <
ionen@gentoo.org>
---
eclass/linux-mod-r1.eclass | 1206 ++++++++++++++++++++++++++++++++++++
1 file changed, 1206 insertions(+)
create mode 100644 eclass/linux-mod-r1.eclass
diff --git a/eclass/linux-mod-r1.eclass b/eclass/linux-mod-r1.eclass
new file mode 100644
index 000000000000..a27809031cb0
--- /dev/null
+++ b/eclass/linux-mod-r1.eclass
@@ -0,0 +1,1206 @@
+# Copyright 2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: linux-mod-r1.eclass
+# @MAINTAINER:
+# Ionen Wolkens <
ionen@gentoo.org>
+# Gentoo Kernel project <
kernel@gentoo.org>
+# @AUTHOR:
+# Ionen Wolkens <
ionen@gentoo.org>
+# @SUPPORTED_EAPIS: 8
+# @PROVIDES: linux-info
+# @BLURB: Functions for installing out-of-tree Linux kernel modules
+# @DESCRIPTION:
+# See the linux-mod-r1_src_compile function documentation for in-depth
+# usage, and see the example further down for a quick overview.
+#
+# @SUBSECTION linux-mod -> linux-mod-r1 migration overview
+# 0. Define a src_compile if mi