[PATCH 1/2] Documentation: kunit: Test Kconfig entries shouldn't select other configs

[David Gow]

Add a note to the Kconfig section of style.rst to use 'depends on' rather
than 'selects' for dependencies, as this can cause users of
CONFIG_KUNIT_ALL_TESTS to suddenly grow unexpected dependencies.

Signed-off-by: David Gow <da...@davidgow.net>
---
Documentation/dev-tools/kunit/style.rst | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst
index eac81a714a29..449f9f816fc7 100644
--- a/Documentation/dev-tools/kunit/style.rst
+++ b/Documentation/dev-tools/kunit/style.rst
@@ -164,9 +164,10 @@ This Kconfig entry must:
* be visible only if ``CONFIG_KUNIT_ALL_TESTS`` is not enabled.
* have a default value of ``CONFIG_KUNIT_ALL_TESTS``.
* have a brief description of KUnit in the help text.
-
-If we are not able to meet above conditions (for example, the test is unable to
-be built as a module), Kconfig entries for tests should be tristate.
+* depend on the feature being tested, rather than selecting it (so that
+ enabling ``CONFIG_KUNIT_ALL_TESTS`` does not enable unrelated functionality).
+* be ``tristate``, unless there is a specific reason that the test cannot be
+ built as a module.

For example, a Kconfig entry might look like:

--
2.54.0

[David Gow]

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 <da...@davidgow.net>
---

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
kuni...@googlegroups.com.
--
2.54.0

[Geert Uytterhoeven]

Hi David,

On Sat, 27 Jun 2026 at 10:29, David Gow <da...@davidgow.net> wrote:
> Add a note to the Kconfig section of style.rst to use 'depends on' rather
> than 'selects' for dependencies, as this can cause users of
> CONFIG_KUNIT_ALL_TESTS to suddenly grow unexpected dependencies.
>
> Signed-off-by: David Gow <da...@davidgow.net>

Thanks for your patch!

> --- a/Documentation/dev-tools/kunit/style.rst
> +++ b/Documentation/dev-tools/kunit/style.rst
> @@ -164,9 +164,10 @@ This Kconfig entry must:
> * be visible only if ``CONFIG_KUNIT_ALL_TESTS`` is not enabled.
> * have a default value of ``CONFIG_KUNIT_ALL_TESTS``.
> * have a brief description of KUnit in the help text.
> -
> -If we are not able to meet above conditions (for example, the test is unable to
> -be built as a module), Kconfig entries for tests should be tristate.
> +* depend on the feature being tested, rather than selecting it (so that
> + enabling ``CONFIG_KUNIT_ALL_TESTS`` does not enable unrelated functionality).
> +* be ``tristate``, unless there is a specific reason that the test cannot be
> + built as a module.

The addition of the second bullet is not mentioned in the commit message
(but I strongly agree with adding it ;-)

>
> For example, a Kconfig entry might look like:
>

\
Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds