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.
I hate this kind of READV and WRITEV macros that Gustavo seems to love.
clang-analyzer hates them as well.
I'm not motivated enough to refactor this, but I want a clean clang
report, so just shut it up.
If we don't have --gc-sections support, linking kmod fails:
libkmod/.libs/libkmod-util.a(libkmod-util.o): In function 'underscores':
libkmod/libkmod-util.c:117: undefined reference to 'kmod_log'
This is because libkmod-util.la uses kmod_log(), that is in libkmod.la.
Move the function so we don't have a dependency loop while building the
libraries and it works with compilers with no support for --gc-sections.
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.
There's no reason kmod_log should be exported, remove it from linker
script. This doesn't break the API/ABI because we are luck: since the
function had visibility=hidden it was not getting exported as a global
symbol.
This reverts commit 88a170dbd6.
There's no reason for users of the API to call this method, it's just
wrong to export it.
The bug that this patch fixed needs to be fixed another way, not
exporting this function.
Previously, depmod would relegate failures of kmod_module_get_symbols()
to debug output, assuming the "error" was simply a lack of symbols.
Leave the ENOENT return to debug output, but report anything else as a
real error.
zlib won't necessarily set the system errno, and this is particularly
evident on corrupted data (which results in a double free). Use zlib's
gzerror to detect the failure, returning a generic EINVAL when zlib
doesn't provide us with an errno.
If we don't have --gc-sections support, linking kmod fails:
libkmod/.libs/libkmod-util.a(libkmod-util.o): In function 'underscores':
libkmod/libkmod-util.c:117: undefined reference to 'kmod_log'
This is because kmod_log is missing the export define, even though it's
already listed in the exported symbol list.
init_module returns -ENOENT when the module failed to load because of a
bad parameter or unknown symbol. Throw a more descriptive error message
than the generic "No such file or directory" to alert the user.
Fixes Debian bug 668216.
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
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
Lucas De Marchi
Lucas De Marchi
Josh Boyer
Mike Frysinger
Dan McGee
Dave Reisner
Kay Sievers
Elan Ruusamäe
Randy Witt