summaryrefslogtreecommitdiffstats
path: root/include/kunit
diff options
context:
space:
mode:
authorJanusz Krzysztofik <janusz.krzysztofik@linux.intel.com>2023-08-07 12:23:55 +0200
committerShuah Khan <skhan@linuxfoundation.org>2023-08-08 21:46:13 +0200
commit18258c60f8a74b9c39b593d118f13f3265d44cd6 (patch)
treea3deb7c95ac870929c75d1cc21b079c67e2ccd2f /include/kunit
parentkunit: Report the count of test suites in a module (diff)
downloadlinux-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.h2
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);