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 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>
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"
The second test, that creates the module by name and then retrieves the
initstate was broken before b95fa91 ('Fix race while loading modules').
We would check /sys and return either builtin (if the module has
parameters) or give an error because we don't find the module (even if
it's in the modules.builtin index)
Some tests cover internal API that wasn't used
elsewhere. The choice here was to test and keep the
list implementation complete instead of removing it.
Keep around a stamp-rootfs file that is generated together with the
rootfs. testsuite checks each test directory if its mtime is greater
than stamp's mtime, deciding if rootfs should be re-generated.
Add a modprobe.conf with some blacklist entries in a test rootfs, and
then ensure our blacklist function actually cuts out the two listed
entries (and doesn't cut out the others).
We can't use the rootfs directory because it breaks out-of-tree build
and in future we want to make modifications to the fake filesystem such
as adding and removing files.
We need to call "chmod -R +w" in the resulting directory because when we
distribute the source with make dist all files will be readonly.
Fix 'make distcheck'
The current configuration is dumb in any number of ways:
1) If the rationale was for space savings, it works the opposite- the
git repo gets more bloated because we are adding binary compressed
blobs that share little in common with their parent, and anyone that
wants to run the test suite has to unzip it anyway.
2) It is a pain in the butt to add new tests, and not accidentally lose
any new rootfs you built in the directory.
3) `git status` won't help you if you are tweaking files in the rootfs
and don't know they have been changed, or if some test did that and
you couldn't detect it.
4) `git log` won't help you find out what is changing in the rootfs test
directory itself when changes are made to the binary blob, such as
new files being added or even existing files being tweaked.
5) The files just aren't that big anyway- 2.7MB unzipped.
test 1 - check whether modprobe outputs the right thing when
using --show-depends is used with already loaded modules.
test 2 - check whether modprobe outputs the right thing when
using --show-depends with modules not loaded yet
Add kmod-* prefixed tool names, add 'tags' in root directory (for ctags,
matches cscope.out ignore already in there), and prefix tools/ entries
with '/' so they are absolute ignores and don't apply to subdirectories.
These ext4 modules were sent by Jon Master so we can test the result of
modinfo with modules generated for different architectures.
They are now added to testsuite and their output tested automatically.
