Make it easier to enable all KUnit fragments. This is useful for kernel
devs or testers, so its easy to get all KUnit tests enabled and if new
gets added they will be enabled as well. Fragments that has to be
builtin will be missed if CONFIG_KUNIT_ALL_TESTS is set as a module.
Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org>
---
lib/kunit/Kconfig | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
index 95d12e3d6d95..bdeee7639005 100644
--- a/lib/kunit/Kconfig
+++ b/lib/kunit/Kconfig
@@ -41,4 +41,18 @@ config KUNIT_EXAMPLE_TEST
is intended for curious hackers who would like to understand how to
use KUnit for kernel development.
+config KUNIT_ALL_TESTS
+ tristate "All KUnit tests with satisfied dependencies"
+ help
+ Enables all KUnit tests, if they can be enabled.
+ KUnit tests run during boot and output the results to the debug log
+ in TAP format (http://testanything.org/). Only useful for kernel devs
+ running the KUnit test harness, and not intended for inclusion into a
+ production build.
+
+ For more information on KUnit and unit tests in general please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
+
+ If unsure, say N.
+
endif # KUNIT
--
2.20.1
Hi,
Here are some patches to update ftracetest to fix some issues.
- [1/3] Fix coloring of XFAIL
- [2/3] Fix a testcase not to expect just one event entry
- [3/3] Do not use built-in echo because the behavior is different
on dash and bash. (Thanks Liu for reporting!)
Thank you,
---
Masami Hiramatsu (3):
selftests/ftrace: Make XFAIL green color
selftests/ftrace: Pick only the first kprobe event to test
selftests/ftrace: Use /bin/echo instead of built-in echo
tools/testing/selftests/ftrace/ftracetest | 2 +-
tools/testing/selftests/ftrace/test.d/functions | 3 +++
.../ftrace/test.d/kprobe/kprobe_args_type.tc | 2 +-
.../test.d/trigger/trigger-trace-marker-hist.tc | 2 +-
.../trigger-trace-marker-synthetic-kernel.tc | 4 ++++
.../trigger/trigger-trace-marker-synthetic.tc | 4 ++--
6 files changed, 12 insertions(+), 5 deletions(-)
--
Masami Hiramatsu (Linaro) <mhiramat(a)kernel.org>
This series fixes a bug in the map_lookup_and_delete_elem() function which
should check for the FMODE_CAN_READ bit, because it returns data to user space.
The rest of commits fix some typos and comment in selftests and extend the
test_map_wronly test to cover the new check for the BPF_MAP_TYPE_STACK and
BPF_MAP_TYPE_QUEUE map types.
Anton Protopopov (5):
selftests/bpf: fix a typo in test_maps
selftests/bpf: cleanup some file descriptors in test_maps
selftests/bpf: cleanup comments in test_maps
bpf: fix map permissions check
selftests/bpf: add tests for write-only stacks/queues
kernel/bpf/syscall.c | 3 +-
tools/testing/selftests/bpf/test_maps.c | 52 ++++++++++++++++++++++---
2 files changed, 49 insertions(+), 6 deletions(-)
--
2.20.1
Hi!
I'm wondering how out of tree check is supposed to work for make
O=dir run_tests from selftests (or make -C ...) directory?
(both with 051f278e9d81 ("kbuild: replace KBUILD_SRCTREE with
boolean building_out_of_srctree") and without)
make M= ... does not work with run_tests.
--
WBR,
Yauheni Kaliuta
On Tue, 26 May 2020, Emanuele Giuseppe Esposito wrote:
> Add kunit tests to extensively test the stats_fs API functionality.
>
I've added in the kunit-related folks.
> In order to run them, the kernel .config must set CONFIG_KUNIT=y
> and a new .kunitconfig file must be created with CONFIG_STATS_FS=y
> and CONFIG_STATS_FS_TEST=y
>
It looks like CONFIG_STATS_FS is built-in, but it exports
much of the functionality you are testing. However could the
tests also be built as a module (i.e. make CONFIG_STATS_FS_TEST
a tristate variable)? To test this you'd need to specify
CONFIG_KUNIT=m and CONFIG_STATS_FS_TEST=m, and testing would
simply be a case of "modprobe"ing the stats fs module and collecting
results in /sys/kernel/debug/kunit/<module_name> (rather
than running kunit.py). Are you relying on unexported internals in
the the tests that would prevent building them as a module?
Thanks!
Alan
Hi, Andrii!
>>>>> On Tue, 26 May 2020 15:32:10 -0700, Andrii Nakryiko wrote:
> On Thu, May 21, 2020 at 11:41 PM Yauheni Kaliuta
> <yauheni.kaliuta(a)redhat.com> wrote:
>>
>>
>> Actually, a bit more needed :)
> From the other kselftest thread, it seems like selftests are not
> supporting builds out-of-tree. With that, wouldn't it be simpler to
> build in tree and then just copy selftests/bpf directory to wherever
> you need to run tests from? It would be simple and reliable. Given I
> and probably everyone else never build and run tests out-of-tree, it's
> just too easy to break this and you'll be constantly chasing some
> non-obvious breakages...
> Is there some problem with such approach?
This is `make install` ;).
I personally do not need OOT build, but since it's in the code,
I'd prefer either fix it or remove it, otherwise it's
misleading. But I have not got reply from kselftest.
>>
>> >>>>> On Fri, 22 May 2020 07:13:02 +0300, Yauheni Kaliuta wrote:
>>
>> > I had a look, here are some fixes.
>> > Yauheni Kaliuta (8):
>> > selftests/bpf: remove test_align from Makefile
>> > selftests/bpf: build bench.o for any $(OUTPUT)
>> > selftests/bpf: install btf .c files
>> > selftests/bpf: fix object files installation
>> > selftests/bpf: add output dir to include list
>> > selftests/bpf: fix urandom_read installation
>> > selftests/bpf: fix test.h placing for out of tree build
>> > selftests/bpf: factor out MKDIR rule
>>
>> > tools/testing/selftests/bpf/Makefile | 77 ++++++++++++++++++++--------
>> > 1 file changed, 55 insertions(+), 22 deletions(-)
>>
>> > --
>> > 2.26.2
>>
>>
>> --
>> WBR,
>> Yauheni Kaliuta
>>
--
WBR,
Yauheni Kaliuta
Hi, all.
I met a strange problem that kunit run 0 tests in Debian9.
Env:
```
root@lkp-hsw-ep4 ~/linus# head /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
root@lkp-hsw-ep4 ~/linus# uname -r
5.6.0
```
Reproduce: Just run `./tools/testing/kunit/kunit.py run --defconfig`
```
root@lkp-hsw-ep4 ~/linus# ./tools/testing/kunit/kunit.py run --defconfig
[13:41:30] Building KUnit Kernel ...
[13:41:33] Starting KUnit Kernel ...
[13:41:33] ============================================================
[13:41:33] Testing complete. 0 tests run. 0 failed. 0 crashed.
[13:41:33] Elapsed time: 2.619s total, 0.002s configuring, 2.610s
building, 0.007s running
root@lkp-hsw-ep4 ~/linus# cat .kunitconfig
CONFIG_KUNIT=y
CONFIG_KUNIT_TEST=y
CONFIG_KUNIT_EXAMPLE_TEST=y
```
As doc said, looks like everything worked correctly. But kunit run 0 tests.
```
If everything worked correctly, you should see the following:
Generating .config ...
Building KUnit Kernel ...
Starting KUnit Kernel ...
```
--
Best regards.
Liu Yiding