Lines Matching +full:re +full:- +full:config
1 .. SPDX-License-Identifier: GPL-2.0
11 --------------------------
15 .. code-block:: bash
18 ( cd "$(git rev-parse --show-toplevel)" && ./tools/testing/kunit/kunit.py run $@ )
26 -------------------------
33 .. code-block:: bash
35 $ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' > .kunit/.kunitconfig
38 We're paying the cost of building more tests than we need this way, but it's
46 -----------------------
48 ``kunit.py run`` (along with ``build``, and ``config``) supports a
49 ``--kunitconfig`` flag. So if you have a set of tests that you want to run on a
55 .. code-block:: bash
57 $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit/.kunitconfig
59 Alternatively, if you're following the convention of naming your
62 .. code-block:: bash
64 $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit
70 config is useful enough to submit (and therefore have to maintain).
75 files to make it possible to have a top-level config run tests from all
77 longer just simple .config fragments.
84 -------------------------------------
86 You can use ``--kernel_args`` to pass arbitrary kernel arguments, e.g.
88 .. code-block:: bash
90 $ ./tools/testing/kunit/kunit.py run --kernel_args=param=42 --kernel_args=param2=false
94 ------------------------------------------
98 versions of gcc 7 and up. You're likely to run into missing ``.gcda``
102 documented in Documentation/dev-tools/gcov.rst.
106 .. code-block:: none
113 Putting it together into a copy-pastable sequence of commands:
115 .. code-block:: bash
117 # Append coverage options to the current config
118 $ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig
121 $ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/
125 $ genhtml -o /tmp/coverage_html coverage.info
130 .. code-block:: bash
132 $ ./tools/testing/kunit/kunit.py run --make_options=CC=/usr/bin/gcc-6
133 $ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ --gcov-tool=/usr/bin/gcov-6
145 non-UML architectures.
148 Running built-in tests
149 ----------------------
153 ``.config``, build and boot your kernel as normal.
157 .. code-block:: none
164 .. code-block:: none
171 ok 1 - example_simple_test
172 ok 1 - example
175 ------------------------
179 For example, we'd change the config options from before to
181 .. code-block:: none
188 .. code-block:: none
190 $ modprobe kunit-example-test
195 The ``modprobe`` will *not* have a non-zero exit code if any test
203 As of 5.13, the only difference is that ``current->kunit_test`` will
206 Pretty-printing results
207 -----------------------
212 .. code-block:: bash
218 ----------------------------
220 Regardless of how you're running your tests, you can enable
221 ``CONFIG_KUNIT_DEBUGFS`` to expose per-suite TAP-formatted results:
223 .. code-block:: none
231 So using our example config:
233 .. code-block:: bash
235 $ modprobe kunit-example-test > /dev/null
240 $ modprobe -r kunit-example-test
245 --------------------------------
247 See Documentation/dev-tools/gcov.rst for details on how to do this.
249 The only vaguely KUnit-specific advice here is that you probably want to build
253 .. code-block:: bash
257 $ modprobe kunit-example-test