Commit c4714b00 authored by Lothar Rubusch's avatar Lothar Rubusch Committed by Shuah Khan

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: default avatarLothar Rubusch <l.rubusch@gmail.com>
Reviewed-by: default avatarBrendan Higgins <brendanhiggins@google.com>
Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
parent 45ba7a89
...@@ -32,15 +32,17 @@ test targets as well. The ``.kunitconfig`` should also contain any other config ...@@ -32,15 +32,17 @@ test targets as well. The ``.kunitconfig`` should also contain any other config
options required by the tests. options required by the tests.
A good starting point for a ``.kunitconfig`` is the KUnit defconfig: A good starting point for a ``.kunitconfig`` is the KUnit defconfig:
.. code-block:: bash .. code-block:: bash
cd $PATH_TO_LINUX_REPO cd $PATH_TO_LINUX_REPO
cp arch/um/configs/kunit_defconfig .kunitconfig cp arch/um/configs/kunit_defconfig .kunitconfig
You can then add any other Kconfig options you wish, e.g.: You can then add any other Kconfig options you wish, e.g.:
.. code-block:: none .. 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 :doc:`kunit_tool <kunit-tool>` will ensure that all config options set in
``.kunitconfig`` are set in the kernel ``.config`` before running the tests. ``.kunitconfig`` are set in the kernel ``.config`` before running the tests.
...@@ -54,8 +56,8 @@ using. ...@@ -54,8 +56,8 @@ using.
other tools (such as make menuconfig) to adjust other config options. 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 To make sure that everything is set up correctly, simply invoke the Python
wrapper from your kernel repo: wrapper from your kernel repo:
...@@ -105,8 +107,9 @@ have config options ending in ``_KUNIT_TEST``. ...@@ -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 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. 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 Build and run your kernel as usual. Test output will be written to the kernel
log in `TAP <https://testanything.org/>`_ format. log in `TAP <https://testanything.org/>`_ format.
......
...@@ -595,7 +595,7 @@ able to run one test case per invocation. ...@@ -595,7 +595,7 @@ able to run one test case per invocation.
KUnit debugfs representation KUnit debugfs representation
============================ ============================
When kunit test suites are initialized, they create an associated directory 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 - results: "cat results" displays results of each test case and the results
of the entire suite for the last test run. 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 ...@@ -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 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 to display results like this is valuable as otherwise results can be
intermixed with other events in dmesg output. The maximum size of each 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 { ...@@ -175,7 +175,7 @@ struct kunit_suite {
void (*exit)(struct kunit *test); void (*exit)(struct kunit *test);
struct kunit_case *test_cases; struct kunit_case *test_cases;
/* private - internal use only */ /* private: internal use only */
struct dentry *debugfs; struct dentry *debugfs;
char *log; char *log;
}; };
...@@ -232,12 +232,12 @@ void __kunit_test_suites_exit(struct kunit_suite **suites); ...@@ -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 * kunit_test_suites() - used to register one or more &struct kunit_suite
* with KUnit. * 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. * 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 * that they cannot test anything where tests must run at a different init
* phase. One significant restriction resulting from this is that KUnit * phase. One significant restriction resulting from this is that KUnit
* cannot reliably test anything that is initialize in the late_init phase; * 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); ...@@ -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 * tests from the same place, and at the very least to do so after
* everything else is definitely initialized. * everything else is definitely initialized.
*/ */
#define kunit_test_suites(...) \ #define kunit_test_suites(suites_list...) \
static struct kunit_suite *suites[] = { __VA_ARGS__, NULL}; \ static struct kunit_suite *suites[] = {suites_list, NULL}; \
static int kunit_test_suites_init(void) \ static int kunit_test_suites_init(void) \
{ \ { \
return __kunit_test_suites_init(suites); \ return __kunit_test_suites_init(suites); \
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment