The KUnit FAQ was written when KUnit in general, and kunit.py in particular, were very heavily focused on UML. While they were updated slightly when qemu support was added, they've not really kept pace with changes to KUnit or the structure of the rest of the documentation.
Update them to describe how to run kunit.py with non-UML architectures, and to point to the run_manual.rst page for further detail on how to run KUnit without kunit.py, as it's the authoratative documentation on that subject. Signed-off-by: David Gow <[email protected]> --- Documentation/dev-tools/kunit/faq.rst | 43 +++++++++++++++------------ 1 file changed, 24 insertions(+), 19 deletions(-) diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst index fae426f2634a..b1341c1a62d9 100644 --- a/Documentation/dev-tools/kunit/faq.rst +++ b/Documentation/dev-tools/kunit/faq.rst @@ -25,19 +25,21 @@ disqualifying any of them from being considered unit testing frameworks. Does KUnit support running on architectures other than UML? =========================================================== -Yes, mostly. +Yes. KUnit can run on any architecture, though the kunit.py tool can only +build and run kernels for some architectures (of which UML is the default). -For the most part, the KUnit core framework (what we use to write the tests) -can compile to any architecture. It compiles like just another part of the -kernel and runs when the kernel boots, or when built as a module, when the -module is loaded. However, there is infrastructure, like the KUnit Wrapper -(``tools/testing/kunit/kunit.py``) that might not support some architectures -(see :ref:`kunit-on-qemu`). +You can build and run tests without kunit.py at all on any architecture by +enabling ``CONFIG_KUNIT=y`` and booting the kernel. +See Documentation/dev-tools/kunit/run_manual.rst for more details. -In short, yes, you can run KUnit on other architectures, but it might require -more work than using KUnit on UML. +Alternatively, kunit.py supports many common architectures using +cross-compilers and the qemu emulator. This can be done using the ``--arch`` +parameter when running the tests, and the ``--cross_compile`` parameter +when building (if the architecture is not supported by the host compiler). +See :ref:`kunit-on-qemu` for more details. -For more information, see :ref:`kunit-on-non-uml`. +When writing tests targeting other architectures, it's worth keeping the tips +on the :ref:`kunit-on-non-uml` page in mind. .. _kinds-of-tests: @@ -78,27 +80,30 @@ things to try. down where an issue is occurring. (If you think the parser is at fault, you can run it manually against ``stdin`` or a file with ``kunit.py parse``.) 3. Running the UML kernel directly can often reveal issues or error messages, - ``kunit_tool`` ignores. This should be as simple as running ``./vmlinux`` - after building the UML kernel (for example, by using ``kunit.py build``). + ``kunit_tool`` ignores. This should be as simple as runningi the ``vmlinux`` + binary in the output directory (by default ``./.kunit/vmlinux``) after + building the UML kernel (for example, by using ``kunit.py build``). Note that UML has some unusual requirements (such as the host having a tmpfs filesystem mounted), and has had issues in the past when built statically and the host has KASLR enabled. (On older host kernels, you may need to run ``setarch `uname -m` -R ./vmlinux`` to disable KASLR.) -4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test +4. Try running KUnit on a different architecture by using the ``--arch`` + option. On an x86_64 host, using ``--arch=x86_64`` is a good first step. +5. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test (e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config around, so you can see what config was used after running ``kunit.py run``. It also preserves any config changes you might make, so you can enable/disable things with ``make ARCH=um menuconfig`` or similar, and then re-run kunit_tool. -5. Try to run ``make ARCH=um defconfig`` before running ``kunit.py run``. This +6. Try to run ``make ARCH=um defconfig`` before running ``kunit.py run``. This may help clean up any residual config items which could be causing problems. -6. Finally, try running KUnit outside UML. KUnit and KUnit tests can be - built into any kernel, or can be built as a module and loaded at runtime. - Doing so should allow you to determine if UML is causing the issue you're - seeing. When tests are built-in, they will execute when the kernel boots, and +7. Finally, try running KUnit manually, instead of via ``kunit.py``. KUnit can + be built into any kernel, or can be built as a module and loaded at runtime. + When tests are built-in, they will execute when the kernel boots, and modules will automatically execute associated tests when loaded. Test results can be collected from ``/sys/kernel/debug/kunit/<test suite>/results``, and - can be parsed with ``kunit.py parse``. For more details, see :ref:`kunit-on-qemu`. + can be parsed with ``kunit.py parse``. For more details, see + Documentation/dev-tools/kunit/run_manual.rst If none of the above tricks help, you are always welcome to email any issues to [email protected]. -- 2.54.0
