These redirecting makefiles simplifies compiling from some editors and
when CWD is not the root of the source tree. This is similar to what was
introduced in systemd in 340d89e ("build-sys: add small redirecting
Makefiles to simplify compilation from within emacs")
In kcmdline it's possible to have a dot in the param's value. The
support for this was added in 66f3228 ("libkmod: Add support for '.' in
module parameter on kcmdline") and is needed to correctly support some
modules that depend on it.
This test was added in order to make sure the commit aa87854
("libkmod-config: Only match dot before '=' in /proc/cmdline") didn't
break it. Although that commit message says it's allowing to match a
dot before '=' it's actually enforcing the first part of the string to
be always in the format "<module-name>.param". Dots after '=' are still
correctly allowed.
Strings unrelated to modules and modprobe should be ignored and not
appear in the output of "modprobe -c".
This adds a test for the fix provided in aa87854 ("libkmod-config: Only
match dot before '=' in /proc/cmdline").
We are not only checking if those options are correctly parsed from
kcmdline, but if in fact they are being passed to the final
(f)init_module call. This is why we use 'modprobe --show-depends'
instead of the simpler 'modprobe -c'.
Use "modprobe -c" to dump the configuration. Since we configure our
rootfs to have only a /proc/cmdline file, this should dump the knowledge
we have from its parsed content.
Test if <module>.option, without any value is correctly parsed, as fixed
in commit 493dc65 ("libkmod: Fix getting param with no value from kcmdline")
Otherwise, we also parse strings like
BOOT_IMAGE=/boot/vmlinuz-3.12.12-57.g5f654cf-default
In practice, this is not a problem, because there is no module named
BOOT_IMAGE=/boot/vmlinuz-3. It just disturbs in modprobe -c output.
If we can open it and read it, it's good enough for us. Otherwise, we
cannot use -C /dev/null to skip the system configuration for instance:
$ ./tools/modprobe -C /dev/null -c
libkmod: ERROR libkmod/libkmod-config.c:821 conf_files_list: unsupported
file mode /dev/null: 0x21b6
...
Add a ->modules_loaded member to struct test, which is a comma-separated
list of modules that should be present after the test finishes. Both
missing and excess modules cause an error.
Also define noreturn w/o <stdnoreturn.h> and move it to macro.h instead
of in the testsuite.
Based on similar commit on systemd by Shawn Landden
<shawn@churchofgit.com>.
This allows make rules for generated build files (i.e. configure,
Makefile.in, ... ) to be skipped. This is useful when
the source is stored without timestamps (for example in CVS or GIT).
When the build rules trigger to regenerate the build files, it tries to
use the same autotools version (currently 1.14) as was originally used
for the release. Since many of our build machines run Debian Squeeze,
they only have autotools 1.11 available and the build fails.
Currently, we have to work around this by touching all the generated
files before building to avoid triggering the make rule. With this
patch, we would be able to just run configure with
--disable-maintainer-mode instead. The patch sets the default to enable
to not change the default behavior.
If we are note building in the existing source tree and have disabled
dependency-tracking then the testsuite directory is not created during
the configure phase and will not exist when the cp of ROOTFS_PRISTINE
occurs, thus causing an error and fail.
By aligning n_buckets to power of 2 we can turn the "bucket = hashval %
n_buckets" into a less expensive bucket = hashval & (n_buckets - 1).
This removes the DIV instruction as shown below.
Before:
xor %edx,%edx
divl 0x8(%rbx)
mov %edx,%eax
add $0x1,%rax
shl $0x4,%rax
add %rbx,%rax
After:
lea -0x1(%rdi),%edx
and %edx,%eax
add $0x1,%rax
shl $0x4,%rax
add %rbx,%rax
With a microbenchmark, measuring the time to locate the bucket (i.e.
time_to_calculate_hashval + time_to_calculate_bucket_position) we have
the results below (time in clock cycles):
keylen before after
2-10 79.0 61.9 (-21.65%)
11-17 81.0 64.4 (-20.48%)
18-25 90.0 73.2 (-18.69%)
26-32 104.7 87.0 (-16.82%)
33-40 108.4 89.6 (-17.37%)
41-48 111.2 91.9 (-17.38%)
49-55 120.1 102.1 (-15.04%)
56-63 134.4 115.7 (-13.91%)
As expected the gain is constant, regardless of the key length.
The time to clculate the hashval varies with the key length, which
explains the bigger gains for short keys.
Add static inline function to align a value to it's next power of 2.
This is commonly done by a SWAR like the one in:
http://aggregate.org/MAGIC/#Next Largest Power of 2
However a microbench shows that the implementation herer is a faster.
It doesn't really impact the possible user of this function, but it's
interesting nonetheless.
Using a x86_64 i7 Ivy Bridge it shows a ~4% advantage by using clz
instead instead of the OR and SHL chain. And this is by using a BSR
since Ivy Bridge doesn't have LZCNT. New Haswell processors have the
LZCNT instruction which can make this even better. ARM also has a CLZ
instruction so it should be better, too.
Code used to test:
...
v = val[i];
t1 = get_cycles(0);
a = ALIGN_POWER2(v);
t1 = get_cycles(t1);
t2 = get_cycles(0);
v = nlpo2(v);
t2 = get_cycles(t2);
printf("%u\t%llu\t%llu\t%d\n", v, t1, t2, v == a);
...
In which val is an array of 20 random unsigned int, nlop2 is the SWAR
implementation and get_cycles uses RDTSC to measure the performance.
Averages:
ALIGN_POWER2: 30 cycles
nlop2: 31.4 cycles
During the last merge window (3.12) a couple of modules gained devname
aliases, but without the necessary major and minor information. These were
then silently ignored when generating modules.devname.
Complain loudly to avoid such errors sneaking in undetected in the future:
depmod: ERROR: Module 'zram' has devname (zram) but lacks major and minor information. Ignoring.
depmod: ERROR: Module 'uhid' has devname (uhid) but lacks major and minor information. Ignoring.
Cc: Kay Sievers <kay@vrfy.org>
Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
It's used in so many places without checking, that's really pointless to
check for it in macro.h.
Also remove AC_C_TYPEOF from configure.ac since we don't use -ansi.
Commit 8efede20ef ("Use _Static_assert") introduced the usage of
_Static_assert(). However, _Static_assert() is a fairly new thing,
since it was introduced only in gcc 4.6. In order to support older
compilers, this patch adds a configure.in test that checks whether
_Static_assert() is usable or not, and adjust the behavior of the
assert_cc() macro accordingly.
With readdir_r() we should be providing enough space to store the dir
name. This could be accomplished by define an union like systemd does:
union dirent_storage {
struct dirent de;
uint8_t storage[offsetof(struct dirent, d_name) +
((NAME_MAX + 1 + sizeof(long)) & ~(sizeof(long) - 1))];
};
However in all places that we use readdir_r() we have no concerns about
reentrance nor we have problems with threads. Thus use the simpler
readdir() instead.
We also remove the error logging here (that could be added back by
checking errno), but it was not adding much value so it's gone.
stdout and stderr are names reserved for the implementation
and musl uses them rightfully as macro - and the expansion
causes (of course) unexpected results.
rename the struct members stdout to out and stderr
to err, to be 1) compliant 2) cause compilation to
succeed.
fixes build with musl libc.
It occurred to an openSUSE user that our mkinitrd would throw a
warning when used with kmod:
libkmod: conf_files_list: unsupported file mode /dev/null: 0x21b6
Grepping for the error message revealed that there might be a missing
"else" keyword here, since it is unusual to put an "if" directly after
closing brace.
Lucas De Marchi
Michal Marek
Stephen Kitt
Lukas Berk
Anders Olofsson
Saul Wold
Tom Gundersen
Thomas Petazzoni
John Spencer
Jan Engelhardt