Lines Matching refs:we

10 As long as we can build the kernel, we can run KUnit.
44 kunit_tool. This is useful if we have several different groups of
45 tests we want to run independently, or if we want to use pre-defined
64 If we want to run a specific set of tests (rather than those listed
65 in the KUnit ``defconfig``), we can provide Kconfig options in the
90 set in the kernel ``.config`` before running the tests. It warns if we
96    This means that we can use other tools
104 If we want to make manual changes to the KUnit build process, we
106 When running kunit_tool, from a ``.kunitconfig``, we can generate a
113 To build a KUnit kernel from the current ``.config``, we can use the
120 If we already have built UML kernel with built-in KUnit tests, we
136 a summary. To see the raw test results in TAP format, we can pass the
143 If we have KUnit results in the raw TAP format, we can parse them and
159 commands, we can run a subset of the tests built into a kernel . For
160 example: if we only want to run KUnit resource tests, use:
180   Not all architectures currently support this flag, but we can use
190   - ``sparc64-linux-gnu`` if we have the sparc toolchain installed on
194     if we have downloaded the microblaze toolchain from the 0-day
203 When cross-compiling, we'll likely need to specify a different toolchain, for
212 If we want to run KUnit tests on an architecture not supported by
214 non-default configuration; then we can write our own``QemuConfig``.
221 Once we have a ``QemuConfig``, we can pass it into kunit_tool,
252   to enable compiler warnings, we can pass ``--make_options W=1``.
291   - ``sparc64-linux-gnu-`` if we have the sparc toolchain installed on
295     if we have downloaded the microblaze toolchain from the 0-day