forked from fengguang/lkp-tests
-
Notifications
You must be signed in to change notification settings - Fork 157
Kunit Manual
Philip Li edited this page Dec 23, 2022
·
1 revision
There are 2 ways to run kunit tests.
- Build-in kunit test module. (LKP use this way)
- Use kunit.py
- enable kunit kconfigs && rebuild kernel
need_kconfig:
- CONFIG_EXT4_KUNIT_TESTS=m
- CONFIG_KUNIT=y
- CONFIG_KUNIT_EXAMPLE_TEST=m
- CONFIG_KUNIT_TEST=m
- CONFIG_LIST_KUNIT_TEST=m
- CONFIG_SYSCTL_KUNIT_TEST=m
- modprobe kunit module
/lib/modules/5.6.0# modprobe kunit-test
/lib/modules/5.6.0# modprobe kunit-example-test
- check output in dmesg
[ 4503.662787] # Subtest: kunit-try-catch-test
[ 4503.663698] 1..2
[ 4503.664496] ok 1 - kunit_test_try_catch_successful_try_no_catch
[ 4503.666052] ok 2 - kunit_test_try_catch_unsuccessful_try_does_catch
[ 4503.667322] ok 4 - kunit-try-catch-test
[ 4503.668139] # Subtest: kunit-resource-test
[ 4503.669023] 1..5
[ 4503.670082] ok 1 - kunit_resource_test_init_resources
[ 4503.671117] ok 2 - kunit_resource_test_alloc_resource
[ 4503.672424] ok 3 - kunit_resource_test_destroy_resource
[ 4503.673792] ok 4 - kunit_resource_test_cleanup_resources
[ 4503.675046] ok 5 - kunit_resource_test_proper_free_ordering
[ 4503.676121] ok 5 - kunit-resource-test
[ 4532.799529] # Subtest: example
[ 4532.800168] 1..1
[ 4532.804532] # example_simple_test: initializing
[ 4532.805496] ok 1 - example_simple_test
[ 4532.806277] ok 6 - example
- Need install python3 (>= 3.6)
If you can't install python 3.7 by package managers directly, please add below file and run
lkp install kunit.yaml
.
~/lkp-tests$ cat distro/depends/kunit-dev
libffi-dev
zlib1g-dev
liblz-dev
~/lkp-tests$ cat pkg/kunit/PKGBUILD
pkgname=kunit
pkgver=3.7.6
pkgrel=1
pkgdesc=""
arch=(i386 x86_64)
url="https://www.python.org/ftp/python"
license=('GPL')
depends=('')
source=("https://www.python.org/ftp/python/${pkgver}/Python-${pkgver}.tgz")
md5sums=('SKIP')
build() {
tar -zxvf "${srcdir}/Python-${pkgver}.tgz"
cd "${srcdir}/Python-${pkgver}"
./configure
make
}
package() {
cd "${srcdir}/Python-${pkgver}"
make DESTDIR="${pkgdir}" install
}
- Clone linux project and ensure your current env could build kernel
Some dependent packages.
~/lkp-tests$ cat distro/depends/kunit
git
gcc
bison
flex
libelf-dev
libssl-dev
make
libc6-dev
- ./tools/testing/kunit/kunit.py run --defconfig
[09:47:14] Building KUnit Kernel ...
[09:47:21] Starting KUnit Kernel ...
[09:47:21] ============================================================
[09:47:21] ======== [PASSED] kunit-try-catch-test ========
[09:47:21] [PASSED] kunit_test_try_catch_successful_try_no_catch
[09:47:21] [PASSED] kunit_test_try_catch_unsuccessful_try_does_catch
[09:47:21] ============================================================
[09:47:21] ======== [PASSED] kunit-resource-test ========
[09:47:21] [PASSED] kunit_resource_test_init_resources
[09:47:21] [PASSED] kunit_resource_test_alloc_resource
[09:47:21] [PASSED] kunit_resource_test_destroy_resource
[09:47:21] [PASSED] kunit_resource_test_cleanup_resources
[09:47:21] [PASSED] kunit_resource_test_proper_free_ordering
[09:47:21] ============================================================
[09:47:21] ======== [PASSED] kunit-log-test ========
[09:47:21] [PASSED] kunit_log_test
[09:47:21] ============================================================
[09:47:21] ======== [PASSED] string-stream-test ========
[09:47:21] [PASSED] string_stream_test_empty_on_creation
[09:47:21] [PASSED] string_stream_test_not_empty_after_add
[09:47:21] [PASSED] string_stream_test_get_string
[09:47:21] ============================================================
[09:47:21] ======== [PASSED] example ========
[09:47:21] [PASSED] example_simple_test
[09:47:21] ============================================================
[09:47:21] Testing complete. 12 tests run. 0 failed. 0 crashed.
[09:47:21] Elapsed time: 7.401s total, 0.005s configuring, 7.261s building, 0.135s running
From David Gow [email protected]
A few questions/suggestions:
- Are there any test results visible when running
./tools/testing/kunit/kunit.py run --raw_output (older versions of
the KUnit parser may not work well if the kernel log is decorated,
e.g. with timestamps, etc — this should be largely fixed for 5.7).
- If not, does running the built UML kernel manually work, and if so
does it print any test results? This should be as simple as running
"./vmlinux". On some older host kernels, UML may not boot if built
statically and KASLR is in its strictest mode. This shouldn't be the
case here, but running "setarch `uname -m` -R ./vmlinux" may help if
some weirder issues show up.
- Does the .config actually have CONFIG_KUNIT_TEST=y and
CONFIG_KUNIT_EXAMPLE_TEST=y? kunit.py will keep its .config around, so
you can check it after running kunit.py run. It'll also preserve any
config changes you make that don't conflict with the .kunitconfig, so
you could try (for example), also enabling CONFIG_LIST_KUNIT_TEST to
see if it's a problem specific to those tests.
- Finally, running 'make ARCH=um defconfig' before running kunit.py
run may help clean up any residual config that could be causing
problems.
- Otherwise, I'm not sure what could be going wrong. Are you running
on x86_64? UML doesn't support non-x86 architectures, and while the
32-bit stuff worked last I checked, it's not tested as regularly at
present.
Of course, it's also possible to run tests without UML or the kunit.py
script as well, by either building them into a kernel, and reading the
results from the log on startup, or building the tests as modules,
modprobing them, and reading the results from
/sys/kernel/debug/kunit/<test-suite>/results. That's obviously a bit
less convenient than the script, but may fit better into existing test
infrastructure, and can sidestep any UML issues.
Hope that helps!
Cheers,
-- David
Try to add option "--raw_output" to ouput details of running progress.