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.
These variables are supposed to be set by user. What we can do in
configure is to set another variable and AC_SUBST() it. Then in
Makefile.am we assign it to AM_{CFLAGS,LDFLAGS}. This way user can
always override their values, in configure or make phase.
Reference: http://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html
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
Ensure this dependency is explicit in the Makefile so rebuilding just
one test works correctly. Also reduce some repetition in the test LDADD
bits by adding a new TESTSUITE_LDADD variable.
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.
In order to locate where the shared libs to be preloaded are we need to
reference them using abs_top_buildir. Otherwise we are limited to
running tests from there.
Distro packagers should create them instead. It's too much trouble to
create them in the build system and every distro wants a different path
for them.
Symlinking tools to kmod doesn't work because argv[0] is not the name of
the symlink, but rather 'kmod' (since libtool's wrapper script calls the
tools/.libs/kmod directly)
Now we create another binary kmod-nolib that is statically linked to
libkmod so we can call the binary directly and do not worry about
LD_LIBRARY_PATH.
Current limitation is horrible no support to sections: we have to to
have separate header files or to maintain the libkmod-sections.txt file.
We are doing the latter.
this is the initial code for depmod, it should:
* use configuration from /run/depmod.d, /etc/depmod.d, /lib/depmod.d
* respect overrides and searches
* resolve symbols and dependencies
* break circular dependencies (dependency loops)
* --errsyms: print out modules with unresolved symbols and incorrect crc
* --symbol-prefix: respect architecture symbol prefix
it will not:
* --quick: does not do quick mode
* --warn: does not warn on duplicates
* --filesyms: does not load symbols from map file
* --symvers: does not load symbol versions from map file
* dump files: does not dump any files at the moment.
it is highly untested, then I appreciate your help with real world
scenarios using overrides and searches. To get output run with -vvvvvv.
next version should fill in the gaps and at least generate the files
build: explicitly call PKG_PROG_PKG_CONFIG
Per the manual page, PKG_PROG_PKG_CONFIG needs to be invoked
explicitly if PKG_CHECK_MODULES might not happen (it is indeed stowed
in an AS_IF in kmod). Without this, funny failures can occur.
(As it did.)
If using libtool 2.4.2, running the script generated by libtool will not
work because libtool changes argv[0] to lt-progname.
To test this is necessary to either fix the installed
build-aux/ltmain.sh file or run the binary directly like in:
$ export LD_LIBRARY_PATH=$PWD/libkmod/.libs/
$ ./tools/.libs/kmod help
It's not possible to move functions related to "live" modules to
libkmod-loaded.c because they depend on the definition of kmod_module.
Putting this structure in the private header is not a good idea, so let
all functions related to "live" information in the end of
libkmod-module.c, and move the sole function from libkmod-loaded.c to
this place. This way all functions get the right documentation
about their sections.
try to mimic original module-init-tools' modprobe as much as possible,
but this exposed some missing features in libkmod, these are now
listed in TODO.
If we create a kmod_module from a name, the path returned is relative to
the module dirname, as passed during kmod_ctx creation. Note that if
kmod_ctx is created with kmod_new(NULL), the dir used is the one
returned by uname.
This effectively makes the combined work be GPL. All other parts of this
library are still LGPL and if this part in future becomes
double-licensed, we can switch back to LGPL.
It doesn't run with `make check' since
o It's dangerous
o It needs to be run as root
o It needs an argument, otherwise it removes the first module
with use_count==0
