On the ARM gcc 4.2.2 I'm using I get many
"--as-needed: linker input file unused because linking not done"
style errors when libtool is using compile mode.
In order to silence these warnings and be "correct", the flags that
only make sense for linking were moved into LDFLAGS.
This is mostly just preparation for the next patch. But this macro is
used for flags that are only needed during linking but that don't
make sense for normal compilation.
I saw this exact type of patch online for systemd, but it never seems to
have actually been incorporated into their attributes.m4.
This matches the change in systemd and udev. Log message on udev's
change by Kay Sievers:
After long consideration we came to the conclusion that user
configuration in /etc should always override the (generally
computer generated) configuration in /run. User configuration
should always be what matters over anything else. Hence rearrange
the search orders accordingly. In general this should change
very little as overriding like this is seldomn done so far,
and the order between /etc and /usr stays the same.
More or less confusing message, but if module is builtin in the live
system, it doesn't mean it's builtin in the target kernel.
Instead we now check if module has a path. It don't have a path only if
it's builtin in the target or if it doesn't exist at all. The latter
should not be a problem since this code is being called from inside the
library. Anyway, put an assert to make sure we get bug reports if any
case slipped in here.
We really haven't paid this code much attention, and it's somewhat
evident in our divergence in behavior from module-init-tools. This patch
asserts the following behavior on exit:
* modprobe -r realmod_notloaded => exit zero
* modprobe -r --first-time realmod_notloaded => exit non-zero
* modprobe -r bogusmod => exit non-zero
If kernel doesn't have support to unload modules,
/sys/module/<modname>/refcnt will not exist and that's ok.
Reported by: Sven Anders <anders@anduras.de>
This is a more generic method of applying filters to module lists. This
deprecates kmod_module_get_filtered_blacklist() which now simply returns
a call to _apply_filter with the extra filter enum arg.
Running two instances of modprobe with the same module should both
succeed or both fail:
modprobe foo&; modprobe foo;
Previously if foo failed to be inserted by the first call, the second one
could return 0 because it may have occurred while the first one was being
processed by kernel (thus marked as "coming").
Now we simply don't check by "coming" in order to decide if we need to
call init_module(). module-init-tools used to spin calling
usleep(100000), but calls to init_module() are already synchronous.
Therefore let kernel synchronize the calls.
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
If a softdep depends on a module in the dependency list of the module
being inserted, we would enter and infinite loop.
Move the "mod->visited = true" assignment to the proper place, hoping it
didn't break other use cases. This is a bug that comes and goes every
now and then. Since we have a testsuite now, a test for this should be
written.
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
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.
A simple case of breakage before this commit:
$ touch aes
$ modinfo aes
filename: /tmp/aes
ERROR: could not get modinfo from 'aes': Invalid argument
Add a new is_module_filename() function that attempts to do more than
just check if the passed argument is a regular file. We look at the name
for a '.ko' string, and if that is found, ensure it is either at the end
of the string or followed by another '.' (for .gz and .xz modules, for
instance). We don't make this second option conditional on the way the
tools are built with compression support; the file is a module file
regardless and should always be treated that way.
When doing this, and noticed in the test suite output, we open the
system modules index unconditionally, even if it is never going to be
used during the modinfo call, which is the case when passing module
filenames directly. For only one module there's not much advantage in
pre-loading the index, so just remove the call to kmod_load_resources().
With-help-from: Dave Reisner <dreisner@archlinux.org>
[lucas.demarchi@profusion.mobi: remove call to kmod_load_resources()]
Commit "af9572c lib/module: check initstate before inserting module"
removed the check for "we should return -EEXIST" and moved it back to
the start of the function. The problem with this is the following
scenario:
- We check if module is in kernel -> no
- We insert the dependencies
<-- External program loads
the module
- We check if module is in kernel -> yes
- We return 0, when we should return -EEXIST
Randy Witt
Lucas De Marchi
Dave Reisner
Wouter van Kesteren
Dan McGee