diff options
author | Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> | 2023-08-07 12:23:55 +0200 |
---|---|---|
committer | Shuah Khan <skhan@linuxfoundation.org> | 2023-08-08 21:46:13 +0200 |
commit | 18258c60f8a74b9c39b593d118f13f3265d44cd6 (patch) | |
tree | a3deb7c95ac870929c75d1cc21b079c67e2ccd2f /include/kunit | |
parent | kunit: Report the count of test suites in a module (diff) | |
download | linux-18258c60f8a74b9c39b593d118f13f3265d44cd6.tar.xz linux-18258c60f8a74b9c39b593d118f13f3265d44cd6.zip |
kunit: Make 'list' action available to kunit test modules
Results from kunit tests reported via dmesg may be interleaved with other
kernel messages. When parsing dmesg for modular kunit results in real
time, external tools, e.g., Intel GPU tools (IGT), may want to insert
their own test name markers into dmesg at the start of each test, before
any kernel message related to that test appears there, so existing upper
level test result parsers have no doubt which test to blame for a specific
kernel message. Unfortunately, kunit reports names of tests only at their
completion (with the exeption of a not standarized "# Subtest: <name>"
header above a test plan of each test suite or parametrized test).
External tools could be able to insert their own "start of the test"
markers with test names included if they new those names in advance.
Test names could be learned from a list if provided by a kunit test
module.
There exists a feature of listing kunit tests without actually executing
them, but it is now limited to configurations with the kunit module built
in and covers only built-in tests, already available at boot time.
Moreover, switching from list to normal mode requires reboot. If that
feature was also available when kunit is built as a module, userspace
could load the module with action=list parameter, load some kunit test
modules they are interested in and learn about the list of tests provided
by those modules, then unload them, reload the kunit module in normal mode
and execute the tests with their lists already known.
Extend kunit module notifier initialization callback with a processing
path for only listing the tests provided by a module if the kunit action
parameter is set to "list" or "list_attr". For user convenience, make the
kunit.action parameter visible in sysfs.
v2: Don't use a different format, use kunit_exec_list_tests() (Rae),
- refresh on top of new attributes patches, handle newly introduced
kunit.action=list_attr case (Rae).
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Rae Moar <rmoar@google.com>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Diffstat (limited to 'include/kunit')
-rw-r--r-- | include/kunit/test.h | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/include/kunit/test.h b/include/kunit/test.h index 3d002e6b252f..6a338a3267ed 100644 --- a/include/kunit/test.h +++ b/include/kunit/test.h @@ -309,6 +309,7 @@ static inline void kunit_set_failure(struct kunit *test) } bool kunit_enabled(void); +const char *kunit_action(void); void kunit_init_test(struct kunit *test, const char *name, char *log); @@ -324,6 +325,7 @@ int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_ void __kunit_test_suites_exit(struct kunit_suite **suites, int num_suites); void kunit_exec_run_tests(struct kunit_suite_set *suite_set, bool builtin); +void kunit_exec_list_tests(struct kunit_suite_set *suite_set, bool include_attr); #if IS_BUILTIN(CONFIG_KUNIT) int kunit_run_all_tests(void); |