We need to cope with the case in which a 32 bits machine is opening a 64
bits kernel module and vice-versa. The offset in `struct module' are
different and do not depend on the architecture we are running, but
rather on the architecture they were created for.
This fixes `make check' in 32 bits machines (since we are shipping 64
bits modules for testing)
Autofoo make the dist dir as readonly. If we copy it, tools needing to
create sysfs entries will not be able to do so, because they can't
create the needed directories/files.
It would be much better if autofoo allowed to let the files as is
instead of converting them to read-only.
This loop is similar to the one that comes with install rules of
alsa-utils package. It can be easily verified by reverting commit
abd5557 and running the testsuite.
Each test must run under 2 seconds. Ideally they should run in much less
than this; just give an arbitrary number so we don't wait forever in
case we reached an infinite loop somewhere.
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.
Search modules.builtin file before saying the module was not found.
Note: these "modules" should not appear as dependencies of other modules
(in modules.dep) even if they appear in modinfo. This fixes the return
code of modprobe with builtin modules.
Also fixes a small coding style issue in module_is_inkernel().
When user tries to load a module that is builtin in kernel, modprobe
should just return 0. This is not happening right now, so mark test as
expected_fail until it gets fixed.
This allows us to prepend an arbitrary item to the PATH environment
variable, meaning we can favor the binaries we just built, rather than
relying on those in the filesystem.
int isn't big enough to hold a FILE* / DIR* on some systems, this causes
segfaults in calls that try to use the resulting FILE* / DIR*:
TESTSUITE: ERR: 'testsuite_rootfs_fopen' [1176160] terminated by signal 11 (Segmentation fault)
TESTSUITE: ERR: FAILED: testsuite_rootfs_fopen
FAIL: testsuite/test-testsuite
...
TESTSUITE: ERR: 'loaded_1' [1176166] terminated by signal 11 (Segmentation fault)
TESTSUITE: ERR: FAILED: loaded_1
FAIL: testsuite/test-loaded
...
TESTSUITE: ERR: 'from_alias' [1176181] terminated by signal 11 (Segmentation fault)
TESTSUITE: ERR: FAILED: from_alias
FAIL: testsuite/test-new-module
For reference on my system:
sizeof(int) = 4
sizeof(long) = 8
sizeof(FILE*) = 8
sizeof(DIR*) = 8
Functions that always call exit() should be marked with attribute
noreturn. With glibc this is not necessary, but it fails to compile with
uClibc otherwise.
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.
Adds a bool to the test struct called 'expected_fail' which can be set
to flip the logic used to determine success and failure. Messaging is
also changed to reflect an unexpected pass or expected fail. This can be
used to write tests which may represent functionality desirable for a
future release.
Alias names may contain dots. However since kmod_module_from_alias()
still calls kmod_module_new_from_name(), the bug is not entirely fixed,
and will be completely corrected in a later patch.
