All of lore.kernel.org
 help / color / mirror / Atom feed
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 6/7] Documentation: kunit: rewrite "Run Tests without kunit_tool"
Date: Sun, 23 Oct 2022 19:54:13 +0700	[thread overview]
Message-ID: <20221023125414.60961-7-bagasdotme@gmail.com> (raw)
In-Reply-To: <20221023125414.60961-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


  parent reply	other threads:[~2022-10-23 12:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-23 12:54 [PATCH 0/7] KUnit documentation rewording Bagas Sanjaya
2022-10-23 12:54 ` [PATCH 1/7] Documentation: kunit: rewrite "Writing Your First Test" section Bagas Sanjaya
2022-10-23 12:54 ` [PATCH 2/7] Documentation: kunit: align instruction code blocks Bagas Sanjaya
2022-10-23 12:54 ` [PATCH 3/7] Documentation: kunit: rewrite the rest of "Getting Started" documentation Bagas Sanjaya
2022-11-11 19:46   ` Daniel Latypov
2022-10-23 12:54 ` [PATCH 4/7] Documentation: kunit: move introduction to its own document Bagas Sanjaya
2022-10-23 12:54 ` [PATCH 5/7] Documentation: kunit: rewrite "Running tests with kunit_tool" Bagas Sanjaya
2022-10-23 12:54 ` Bagas Sanjaya [this message]
2022-10-23 12:54 ` [PATCH 7/7] Documentation: kunit: rewrite usage Bagas Sanjaya
2022-10-23 13:08   ` Bagas Sanjaya
2022-10-23 12:54 ` [PATCH 7/7] Documentation: kunit: rewrite "Writing tests" 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=20221023125414.60961-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.