The following tests to verify weak dependencies have been implemented:
1) modprobe test to check that related weakdep modules are not loaded
due to being a weakdep.
2) depmod test to check weakdep output.
3) user test to check that configuration files with weakdep are parsed
correctly and related weakdep modules can be read correctly from user
applications.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Link: https://lore.kernel.org/r/20240530070836.9438-1-jtornosm@redhat.com
[ Minor whitespace issues and define MODULE_WEAKDEP if it's not defined
already ]
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The data in this file isn't related to installed libraries, so put it in
an abi-neutral location.
pkg.m4 provides macros that also allow the user to override the location
with configure switches.
Bug: https://bugs.gentoo.org/926431
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Before commit e98cef6f3f ("make: install/uninstall tools symlinks to
kmod") it was possible to call `make install DESTDIR=<dir>` multiple
times. Use `ln -sf` so the symlink is always re-created.
It would be preferred to remove install in an empty dir, but there's
not a bad consequence of re-using the same, so let the user decide.
Fixes the following errors while installing for the second time:
ln: failed to create symbolic link '/tmp/inst/usr/bin/insmod': File exists
ln: failed to create symbolic link '/tmp/inst/usr/bin/lsmod': File exists
ln: failed to create symbolic link '/tmp/inst/usr/bin/rmmod': File exists
ln: failed to create symbolic link '/tmp/inst/usr/bin/depmod': File exists
ln: failed to create symbolic link '/tmp/inst/usr/bin/modprobe': File exists
ln: failed to create symbolic link '/tmp/inst/usr/bin/modinfo': File exists
make[3]: *** [Makefile:2679: install-exec-hook] Error 1
make[2]: *** [Makefile:2553: install-exec-am] Error 2
make[1]: *** [Makefile:2439: install-am] Error 2
make: *** [Makefile:1848: install-recursive] Error 1
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Closes: https://github.com/kmod-project/kmod/issues/35
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://lore.kernel.org/r/20240306145804.135709-1-lucas.de.marchi@gmail.com
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The kmod insert/remove tools were introduced back in 2015. Since then
they have recieved zero attention, unlike the insmod/rmmod variants.
Glancing around - neither of the following distributions (Arch, Fedora,
Gentoo, Debian) build them, so we're safe to say they have no users.
Remove them and alongside it the --enable-experimental toggle, which no
longer controls anything.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://lore.kernel.org/r/20240212-rm-experimental-v1-1-b97ab3004ae3@gmail.com
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Currently we create symlinks like modprobe (pointing to kmod), during
the normal `make` build. Although those were never installed.
Add a few lines in the install-exec-hook, to ensure they're present at
`make install` time. Thus one can actually use those without additional
changes. As an added bonus, distributions can drop the similar hunk from
their packaging.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
[ Use a relative symlink ]
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Python bindings are not well maintained. Currently it's just broken when
trying to build with cython 3.0.8:
make --no-print-directory all-recursive
Making all in .
CYTHON libkmod/python/kmod/kmod.c
Error compiling Cython file:
------------------------------------------------------------
...
# details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with python-kmod. If not, see <http://www.gnu.org/licenses/>.
cimport _libkmod_h
^
Nothing really touched those bindings for 10 years already.
I postponed the removal since they were at least building, but that just
changed. So let's drop it and allow any interested people to give it
a better life outside of libkmod.
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Now that modprobe.d is searched under ${prefix}/lib, allow a complete
transition to files only under ${prefix} by adding a ${module_directory}
configuration. This specifies the directory where to search for kernel
modules and should match the location where the kernel/distro installs
them.
With this distributions that do not want to ship files in /lib can also
move kernel modules to /usr while others can keep them in /lib.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Link: https://lore.kernel.org/r/a3765f4e8ae3ce29c0847a0132d4a8d51ad040a9.1699618135.git.msuchanek@suse.de
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Show distconfdir (where system configuration files are searched/to be
installed), sysconfdir (where user configuration files are searched),
module compressions, and module signatures supported.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Link: https://lore.kernel.org/r/468b3f572d3b84f25bb53ec8fcb15ed4871914d4.1689681454.git.msuchanek@suse.de
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
There is an ongoing effort to limit use of files outside of /usr (or
${prefix} on general). Currently all modprobe.d paths are hardcoded to
outside of $prefix. Teach kmod to load modprobe.d from ${prefix}/lib.
On some distributions /usr/lib and /lib are the same directory because
of a compatibility symlink, and it is possible to craft configuration
files with sideeffects that would behave differently when loaded twice.
However, the override semantic ensures that one 'overrides' the other,
and only one configuration file of the same name is loaded from any of
the search directories.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Link: https://lore.kernel.org/r/a290343ce32e2a3c25b134e4f27c13b26e06c9e0.1689681454.git.msuchanek@suse.de
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Replace the manual sed command, build rules and dist/clean for using
AC_CONFIG_FILES. It does the exact same thing, with an added bonus...
Currently we're missing version.py.in in the EXTRA_DIST. Thus a simple
"touch Makefile" should retrigger the regeneration of version.py. Which
would presumably fail, since the input file isn't in the distribution
tarball.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Instead of skipping tests if sysconfdir isn't /etc, just handle it
during the rootfs setup logic.
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
It's easier to implement the logic outside of the Makefile, so rename
the populate-modules.sh script to setup-rootfs.sh and move the
additional logic from the makefile to the script.
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
During dpkg build, in a subdir, it is currently not possible to run
tests. Building testsuite/modules due to non-existance of the
testsuite directory under the build dir. Thus create it, when it is
not there.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Since the output needs to be the same, regardless if the module is
compressed, change populate-modules.sh to conditionally compress the
module if that feature is enabled.
This way we can execute the tests with any build-time configuration and
it should still pass.
Suggested-by: Michal Suchánek <msuchanek@suse.de>
Reviewed-by: Michal Suchánek <msuchanek@suse.de>
Tested-by: Michal Suchánek <msuchanek@suse.de>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
I changed the style of the hackargs variable in autogen.sh to multiline
because said line was becoming a bit long with the new --with-zstd arg
added.
A previous version of this patch has been running on my two Arch Linux
installations (with an accompanying mkinitcpio patch) for several months
over many kernel updates without any issues.
Any additional testing and/or patch review would of course be appreciated.
Signed-off-by: Torge Matthies <openglfreak@googlemail.com>
The kernel since version v5.2-rc1 exports information about built-in
modules in the modules.builtin.modinfo. Information is stored in
the same format as in the separate modules (null-terminated string
array). The module name is a prefix for each line.
$ tr '\0' '\n' < modules.builtin.modinfo
ext4.softdep=pre: crc32c
ext4.license=GPL
ext4.description=Fourth Extended Filesystem
ext4.author=Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
ext4.alias=fs-ext4
ext4.alias=ext3
ext4.alias=fs-ext3
ext4.alias=ext2
ext4.alias=fs-ext2
md_mod.alias=block-major-9-*
md_mod.alias=md
md_mod.description=MD RAID framework
md_mod.license=GPL
md_mod.parmtype=create_on_open:bool
md_mod.parmtype=start_dirty_degraded:int
...
Signed-off-by: Alexey Gladkov <gladkov.alexey@gmail.com>
Commit 1d14ef82f4 does not completely fix
the build with python 3.8 as we still get link failure due to
'-z undefs' being ignored by some versions of ld.
Indeed, -z undefs was added by commit
97a232d7335f3bd0231fd9cd39455bde1d563922 in upstream binutils, and this
commit was first present in binutils 2.30.
So any toolchain using binutils version older than that won't have
-z undefs and will build fail on:
/home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/mips-linux-gnu/5.3.0/../../../../mips-linux-gnu/bin/ld: warning: -z undefs ignored.
/home/naourr/work/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/aarch64_be-linux-gnu/7.3.1/../../../../aarch64_be-linux-gnu/bin/ld: warning: -z undefs ignored.
So filter -Wl,--no-undefined to fix the issue
Fixes:
- http://autobuild.buildroot.org/results/e9645d9969481b09f507f6e0d0b35faaa283eb60
- http://autobuild.buildroot.org/results/06a6d865b6b7d8ebd793bde214f4a4c40e0962e1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
kmod's configure.ac uses the -Wl,--no-undefined linker flag to verify
at link time that all symbols of shared libraries are available, and
that there are no undefined symbols.
This make perfect sense for regular shared libraries. However, for
Python extensions, which will be dlopen()ed inside the Python
interpreter, it makes less sense.
Since Python 3.8, there is a change in python-config script and
Python's pkg-config file: it no longer links Python extensions with
the libpython library. See
https://docs.python.org/dev/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
which states:
On the other hand, pkg-config python3.8 --libs no longer contains
-lpython3.8. C extensions must not be linked to libpython (except on
Android and Cygwin, whose cases are handled by the script); this
change is backward incompatible on purpose. (Contributed by Victor
Stinner in bpo-36721.)
So, when linking the kmod Python extensions, it currently fails with
numerous unresolved symbols, that were previously provided by
libpython:
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/7.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: libkmod/python/kmod/.libs/list_la-list.o: in function `__Pyx_PyObject_GetAttrStr':
list.c:(.text.__Pyx_PyObject_GetAttrStr+0x48): undefined reference to `PyObject_GetAttr'
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/7.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: libkmod/python/kmod/.libs/list_la-list.o: in function `__pyx_tp_dealloc_4kmod_4list_ModListItem':
list.c:(.text.__pyx_tp_dealloc_4kmod_4list_ModListItem+0x78): undefined reference to `PyObject_CallFinalizerFromDealloc'
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/7.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: libkmod/python/kmod/.libs/list_la-list.o: in function `__pyx_tp_dealloc_4kmod_4list_ModList':
list.c:(.text.__pyx_tp_dealloc_4kmod_4list_ModList+0x30): undefined reference to `PyErr_Fetch'
[Complete log at http://autobuild.buildroot.net/results/79a/79a5a0398723e8cfea0d0aa3dec5f7649aee4c63/build-end.log]
Linking with libpython is no longer recommended: those symbols should
remain unresolved in the Python extensions, as they wil be properly
resolved when the Python extension gets loaded into the Python
interpreter.
Since we want to keep -Wl,--no-undefined globally in kmod, we leave
the configure.ac file unchanged, and instead, specifically in the
LDFLAGS used to build the Python extensions, we override
-Wl,--no-undefined with -Wl,-z,undefs. Ideally, -Wl,--no-undefined is
the same as -Wl,-z,defs, and the effect of these options can be
canceled on the linker command line by a following -Wl,-z,undefs (see
the ld man page for details).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Victor Stinner <victor.stinner@gmail.com>
In the previous build setup, libkmod.so would link to not just
libcrypto.so, but also libssl.so:
$ readelf -d /lib/libkmod.so | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [liblzma.so.5]
0x0000000000000001 (NEEDED) Shared library: [libz.so.1]
0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.1]
0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
We don't need any symbols from libssl, though. This patch ensures that
we pass 'libcrypto' to pkgconfig rather than 'openssl', getting only the
library that we need:
$ readelf -d ./libkmod/.libs/libkmod.so.2.3.4 | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [liblzma.so.5]
0x0000000000000001 (NEEDED) Shared library: [libz.so.1]
0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
The patch adds data fetching from the PKCS#7 certificate using
openssl library (which is used by scripts/sign-file.c in the linux
kernel to sign modules).
In general the certificate can contain many signatures, but since
kmod (modinfo) supports only one signature at the moment, only first
one is taken.
With the current sign-file.c certificate doesn't contain signer
key's fingerprint, so "serial number" is used for the key id.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Let's just use autogen.sh, no need for wrapper scripts. Now
`autogen.sh c` uses the same recommended options for developing kmod and
also accepts extra arguments.
Instead of using the mkosi.default symlink, use an env var passed from
the build system. We would need to pass the --default switch nonetheless
or change the symlink, making the git tree dirty.
Also, search for installed kernel headers in a way that's compatible
with more distros. On Fedora, for example, the
/usr/lib/modules/<kver>/build symlink is only available if there's a
kernel installed. We don't care about a kernel installed since we don't
need to boot it on a real machine: the only thing we need is the
kernel-devel package.
The patch adds nested loops configuration for the loop test:
mod-loop-h -> mod-loop-i -> mod-loop-j -> mod-loop-k
^ | |
--------------------------- |
| |
-------------------------------------------
making 2 loops with common edges:
mod-loop-h -> mod-loop-i -> mod-loop-j -> mod-loop-h
mod-loop-h -> mod-loop-i -> mod-loop-j -> mod-loop-k -> mod-loop-h
The actual output for the loops is:
depmod: ERROR: Cycle detected: mod_loop_h -> mod_loop_h
depmod: ERROR: Cycle detected: mod_loop_i -> mod_loop_j -> mod_loop_k -> mod_loop_h -> mod_loop_i
(the order in the second doesn't matter, but the first one is
incorrect)
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
install: cannot stat 'testsuite/module-playground/mod-loop-f.ko': No
such file or directory
Makefile:2881: recipe for target 'rootfs' failed
make[1]: *** [rootfs] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:2101: recipe for target 'check-recursive' failed
We need to ship pre-compiled binaries so it's possible to run
"make check" on servers without kernel headers.
Also add them to EXTRA_DIST as other sources.
This should fill the requirements for "we need to loop over a lot of
strings that usually are small enough to remain on stack, but we want to
protect ourselves against huge strings not fitting in the static
buffer we estimated as sufficient"
Makefile.am uses `sed -E', which it is found on BSD sed; however a
replacement on GNU sed would be `sed -r'. Both intend to use extended
regular expressions (ERE). However I have a system that does not support
those, in benefit for portability could you consider replacing ERE by BRE.
Signed-off-by: Héctor Orón Martínez <hector.oron@gmail.com>
Use POSIX Extended Regular Expression (ERE) instead of the GNU extension
\| in the install-exec-hook. This makes it create the symlink properly
with busybox sed built with musl libc. It will silently create a broken
symlink otherwise.
Lucas De Marchi: fix up added newline.
We try to execute git in order to get the dependencies for the coverity
rules. And it gets executed even when we are not calling that specific
rule. Later we may want to improve it, but for now let's just silence
the errors of not being a git repository when executing this on a
packaged version.
