From: Bagas Sanjaya <bagasdotme@gmail.com>
To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com
Cc: Jonathan Corbet <corbet@lwn.net>,
Brendan Higgins <brendan.higgins@linux.dev>,
David Gow <davidgow@google.com>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Khalid Masum <khalid.masum.92@gmail.com>,
Sadiya Kazi <sadiyakazi@google.com>,
Bagas Sanjaya <bagasdotme@gmail.com>
Subject: [PATCH RESEND 6/7] Documentation: kunit: rewrite "Run Tests without kunit_tool"
Date: Sun, 23 Oct 2022 20:08:46 +0700 [thread overview]
Message-ID: <20221023130846.63296-7-bagasdotme@gmail.com> (raw)
In-Reply-To: <20221023130846.63296-1-bagasdotme@gmail.com>
Rewrite the documentation for clarity. Major points:
* Use second-person point of view
* Align and format the first note like other note blocks
* Remove unnecessary lists and trivial modprobe code block (every
developer should have known how to load modules)
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
Documentation/dev-tools/kunit/run_manual.rst | 68 ++++++++------------
1 file changed, 27 insertions(+), 41 deletions(-)
diff --git a/Documentation/dev-tools/kunit/run_manual.rst b/Documentation/dev-tools/kunit/run_manual.rst
index e7b46421f247e1..28c6a1caa0fed0 100644
--- a/Documentation/dev-tools/kunit/run_manual.rst
+++ b/Documentation/dev-tools/kunit/run_manual.rst
@@ -4,54 +4,40 @@
Run Tests without kunit_tool
============================
-If we do not want to use kunit_tool (For example: we want to integrate
-with other systems, or run tests on real hardware), we can
-include KUnit in any kernel, read out results, and parse manually.
+If you do not want to use kunit_tool (e.g. integrating
+with other testing framework or running tests on real hardware), you
+can run KUnit-enabled kernel manually. The test results can be parsed with
+your existing tools.
-.. note:: KUnit is not designed for use in a production system. It is
- possible that tests may reduce the stability or security of
- the system.
+.. note::
-Configure the Kernel
+ Using KUnit is not recommended in production system, since
+ stability and security issues may occur if it is enabled.
+
+Kernel configuration
====================
-KUnit tests can run without kunit_tool. This can be useful, if:
+To enable KUnit, configure the kernel with ``CONFIG_KUNIT`` enabled.
+Individual tests can then be selected. KUnit tests usually (but don't always)
+have configuration name suffixed with ``_KUNIT_TEST``. As with other kernel
+configurations, most tests can be enabled either builtin or as module.
-- We have an existing kernel configuration to test.
-- Need to run on real hardware (or using an emulator/VM kunit_tool
- does not support).
-- Wish to integrate with some existing testing systems.
+.. note::
-KUnit is configured with the ``CONFIG_KUNIT`` option, and individual
-tests can also be built by enabling their config options in our
-``.config``. KUnit tests usually (but don't always) have config options
-ending in ``_KUNIT_TEST``. Most tests can either be built as a module,
-or be built into the kernel.
+ You can enable ``KUNIT_ALL_TESTS``, which automatically enable all
+ tests for which their dependencies can be satisfied. This is a good
+ way of quickly testing everything applicable to the current
+ configuration.
-.. note ::
+Once the kernel have been built and installed, it is simple to run
+the tests just by booting the kernel. If these are builtin, they will run
+automatically. If these are built as modules, they will need to be loaded
+first in order to run them.
- We can enable the ``KUNIT_ALL_TESTS`` config option to
- automatically enable all tests with satisfied dependencies. This is
- a good way of quickly testing everything applicable to the current
- config.
+The test results will be logged in TAP format in ``dmesg``.
-Once we have built our kernel (and/or modules), it is simple to run
-the tests. If the tests are built-in, they will run automatically on the
-kernel boot. The results will be written to the kernel log (``dmesg``)
-in TAP format.
+.. note::
-If the tests are built as modules, they will run when the module is
-loaded.
-
-.. code-block :: bash
-
- # modprobe example-test
-
-The results will appear in TAP format in ``dmesg``.
-
-.. note ::
-
- If ``CONFIG_KUNIT_DEBUGFS`` is enabled, KUnit test results will
- be accessible from the ``debugfs`` filesystem (if mounted).
- They will be in ``/sys/kernel/debug/kunit/<test_suite>/results``, in
- TAP format.
+ If ``CONFIG_KUNIT_DEBUGFS`` is enabled, the test results can
+ be accessed from debugfs (if mounted). Results for each test suite
+ will be in ``/sys/kernel/debug/kunit/<test_suite>/results``.
--
An old man doll... just what I always wanted! - Clara
next prev parent reply other threads:[~2022-10-23 13:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-23 13:08 [PATCH RESEND 0/7] KUnit documentation rewording Bagas Sanjaya
2022-10-23 13:08 ` [PATCH RESEND 1/7] Documentation: kunit: rewrite "Writing Your First Test" section Bagas Sanjaya
2022-10-23 13:08 ` [PATCH RESEND 2/7] Documentation: kunit: align instruction code blocks Bagas Sanjaya
2022-10-23 13:08 ` [PATCH RESEND 3/7] Documentation: kunit: rewrite the rest of "Getting Started" documentation Bagas Sanjaya
2022-10-23 13:08 ` [PATCH RESEND 4/7] Documentation: kunit: move introduction to its own document Bagas Sanjaya
2022-10-23 13:08 ` [PATCH RESEND 5/7] Documentation: kunit: rewrite "Running tests with kunit_tool" Bagas Sanjaya
2022-10-23 13:08 ` Bagas Sanjaya [this message]
2022-10-23 13:08 ` [PATCH RESEND 7/7] Documentation: kunit: rewrite "Writing tests" Bagas Sanjaya
2022-11-10 4:09 ` [PATCH RESEND 0/7] KUnit documentation rewording Bagas Sanjaya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221023130846.63296-7-bagasdotme@gmail.com \
--to=bagasdotme@gmail.com \
--cc=brendan.higgins@linux.dev \
--cc=corbet@lwn.net \
--cc=davidgow@google.com \
--cc=khalid.masum.92@gmail.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=sadiyakazi@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).