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>.
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.
This gives the test cases the ability to supply files that must be
checked after the test is run, rather than just checking stdout/stderr.
This is intended to be used with tools that generate files, like depmod.
It includes a poor's man implementation of a "check for differences in
files". Not really optimized, but it's simple enough and does what it
proposes to.
Only the public header maintains #ifndef in the header, together with
pragma. The other ones contain only pragma.
As reported by Shawn Landden on systemd mailing list this is compatible
with all major compilers and gcc has this since version 3.3.
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.
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.
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.
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.
Tests may put the correct output in a file and tell testsuite to check
if it matches the output from the test running.
Testsuite compares the outputs while running the test: it creates a pipe
between parent and child; parent reads both stdout and stderr from child
and compares with the correct output.
