forked from luck/tmp_suning_uos_patched
Documentation: test.h - fix warnings
Fix warnings at 'make htmldocs', and formatting issues in the resulting documentation. - test.h: Fix annotation in kernel-doc parameter description. - Documentation/*.rst: Fixing formatting issues, and a duplicate label issue due to usage of sphinx.ext.autosectionlabel and identical labels within one document (sphinx warning) Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
This commit is contained in:
parent
45ba7a893a
commit
c4714b0045
|
@ -32,15 +32,17 @@ test targets as well. The ``.kunitconfig`` should also contain any other config
|
|||
options required by the tests.
|
||||
|
||||
A good starting point for a ``.kunitconfig`` is the KUnit defconfig:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd $PATH_TO_LINUX_REPO
|
||||
cp arch/um/configs/kunit_defconfig .kunitconfig
|
||||
|
||||
You can then add any other Kconfig options you wish, e.g.:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
CONFIG_LIST_KUNIT_TEST=y
|
||||
CONFIG_LIST_KUNIT_TEST=y
|
||||
|
||||
:doc:`kunit_tool <kunit-tool>` will ensure that all config options set in
|
||||
``.kunitconfig`` are set in the kernel ``.config`` before running the tests.
|
||||
|
@ -54,8 +56,8 @@ using.
|
|||
other tools (such as make menuconfig) to adjust other config options.
|
||||
|
||||
|
||||
Running the tests
|
||||
-----------------
|
||||
Running the tests (KUnit Wrapper)
|
||||
---------------------------------
|
||||
|
||||
To make sure that everything is set up correctly, simply invoke the Python
|
||||
wrapper from your kernel repo:
|
||||
|
@ -105,8 +107,9 @@ have config options ending in ``_KUNIT_TEST``.
|
|||
KUnit and KUnit tests can be compiled as modules: in this case the tests in a
|
||||
module will be run when the module is loaded.
|
||||
|
||||
Running the tests
|
||||
-----------------
|
||||
|
||||
Running the tests (w/o KUnit Wrapper)
|
||||
-------------------------------------
|
||||
|
||||
Build and run your kernel as usual. Test output will be written to the kernel
|
||||
log in `TAP <https://testanything.org/>`_ format.
|
||||
|
|
|
@ -595,7 +595,7 @@ able to run one test case per invocation.
|
|||
KUnit debugfs representation
|
||||
============================
|
||||
When kunit test suites are initialized, they create an associated directory
|
||||
in /sys/kernel/debug/kunit/<test-suite>. The directory contains one file
|
||||
in ``/sys/kernel/debug/kunit/<test-suite>``. The directory contains one file
|
||||
|
||||
- results: "cat results" displays results of each test case and the results
|
||||
of the entire suite for the last test run.
|
||||
|
@ -604,4 +604,4 @@ The debugfs representation is primarily of use when kunit test suites are
|
|||
run in a native environment, either as modules or builtin. Having a way
|
||||
to display results like this is valuable as otherwise results can be
|
||||
intermixed with other events in dmesg output. The maximum size of each
|
||||
results file is KUNIT_LOG_SIZE bytes (defined in include/kunit/test.h).
|
||||
results file is KUNIT_LOG_SIZE bytes (defined in ``include/kunit/test.h``).
|
||||
|
|
|
@ -175,7 +175,7 @@ struct kunit_suite {
|
|||
void (*exit)(struct kunit *test);
|
||||
struct kunit_case *test_cases;
|
||||
|
||||
/* private - internal use only */
|
||||
/* private: internal use only */
|
||||
struct dentry *debugfs;
|
||||
char *log;
|
||||
};
|
||||
|
@ -232,12 +232,12 @@ void __kunit_test_suites_exit(struct kunit_suite **suites);
|
|||
* kunit_test_suites() - used to register one or more &struct kunit_suite
|
||||
* with KUnit.
|
||||
*
|
||||
* @suites: a statically allocated list of &struct kunit_suite.
|
||||
* @suites_list...: a statically allocated list of &struct kunit_suite.
|
||||
*
|
||||
* Registers @suites with the test framework. See &struct kunit_suite for
|
||||
* Registers @suites_list with the test framework. See &struct kunit_suite for
|
||||
* more information.
|
||||
*
|
||||
* When builtin, KUnit tests are all run as late_initcalls; this means
|
||||
* When builtin, KUnit tests are all run as late_initcalls; this means
|
||||
* that they cannot test anything where tests must run at a different init
|
||||
* phase. One significant restriction resulting from this is that KUnit
|
||||
* cannot reliably test anything that is initialize in the late_init phase;
|
||||
|
@ -253,8 +253,8 @@ void __kunit_test_suites_exit(struct kunit_suite **suites);
|
|||
* tests from the same place, and at the very least to do so after
|
||||
* everything else is definitely initialized.
|
||||
*/
|
||||
#define kunit_test_suites(...) \
|
||||
static struct kunit_suite *suites[] = { __VA_ARGS__, NULL}; \
|
||||
#define kunit_test_suites(suites_list...) \
|
||||
static struct kunit_suite *suites[] = {suites_list, NULL}; \
|
||||
static int kunit_test_suites_init(void) \
|
||||
{ \
|
||||
return __kunit_test_suites_init(suites); \
|
||||
|
|
Loading…
Reference in New Issue
Block a user