From: David Gow <firstname.lastname@example.org>
To: Brendan Higgins <email@example.com>
Cc: Shuah Khan <firstname.lastname@example.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
KUnit Development <email@example.com>,
Linux Kernel Mailing List <firstname.lastname@example.org>,
Jonathan Corbet <email@example.com>,
"open list:DOCUMENTATION" <firstname.lastname@example.org>,
Stephen Boyd <email@example.com>,
Kees Cook <firstname.lastname@example.org>,
Frank Rowand <email@example.com>,
Daniel Latypov <firstname.lastname@example.org>
Subject: Re: [PATCH v1 4/4] Documentation: kunit: document support for QEMU in kunit_tool
Date: Sat, 15 May 2021 16:01:20 +0800 [thread overview]
Message-ID: <CABVgOSnnb=LB2hQOVqarDd3Tv17f7JHHomvSfWeQaFSsH1PD2g@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 4077 bytes --]
On Sat, May 8, 2021 at 5:31 AM Brendan Higgins
> Document QEMU support, what it does, and how to use it in kunit_tool.
> Signed-off-by: Brendan Higgins <email@example.com>
This is a good start, and probably meets the minimum requirements, but
I do have a number of comments and suggestions below.
> Documentation/dev-tools/kunit/usage.rst | 37 +++++++++++++++++++++----
> 1 file changed, 31 insertions(+), 6 deletions(-)
> diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
> index 650f99590df57..b74bd7c87cc20 100644
> --- a/Documentation/dev-tools/kunit/usage.rst
> +++ b/Documentation/dev-tools/kunit/usage.rst
> @@ -612,14 +612,39 @@ only things to be aware of when doing so.
> The biggest impediment will likely be that certain KUnit features and
> infrastructure may not support your target environment. For example, at this
> time the KUnit Wrapper (``tools/testing/kunit/kunit.py``) does not work outside
> -of UML. Unfortunately, there is no way around this. Using UML (or even just a
> -particular architecture) allows us to make a lot of assumptions that make it
> -possible to do things which might otherwise be impossible.
> +of UML and QEMU. Unfortunately, there is no way around this. Using UML and QEMU
> +(or even just a particular architecture) allows us to make a lot of assumptions
> +that make it possible to do things which might otherwise be impossible.
This is a bit more awkward now, and I don't think gives quite the
right impression. Particularly the "Unfortunately, there is no way
around this." bit: there's no fundamental reason that someone couldn't
implement support for some other emulator (or even a setup which
pushed to real hardware and read results over serial), it'd just take
a bit of work to implement (like this patch series has done for qemu).
Personally, I think it'd be easiest to simplify this section and say
that kunit_tool currently only fully supports some architectures, via
UML and QEMU.
> Nevertheless, all core KUnit framework features are fully supported on all
> -architectures, and using them is straightforward: all you need to do is to take
> -your kunitconfig, your Kconfig options for the tests you would like to run, and
> -merge them into whatever config your are using for your platform. That's it!
> +architectures, and using them is straightforward: Most popular architectures
> +are supported directly in the KUnit Wrapper via QEMU. Currently, supported
> +architectures on QEMU include:
> +* i386
> +* x86_64
> +* arm
> +* arm64
> +* alpha
> +* powerpc
> +* riscv
> +* s390
> +* sparc
> +In order to run KUnit tests on one of these architectures via QEMU with the
> +KUnit wrapper, all you need to do is specify the flags ``--arch`` and
> +``--cross_compile`` when invoking the KUnit Wrapper. For example, we could run
> +the default KUnit tests on ARM in the following manner (assuming we have an ARM
> +toolchain installed):
> +.. code-block:: bash
> + tools/testing/kunit/kunit.py run --timeout=60 --jobs=12 --arch=arm --cross_compile=arm-linux-gnueabihf-
Is it worth also documenting the --qemu_config option here?
(Particularly given the restriction on its path?) Or is that something
best added to the kunit_tool page?
That being said, changes to the kunit_tool page are probably worth
adding as a section in the updated page:
At the very least, it'd be nice to have the new QEMU-related options
> +Alternatively, if you want to run your tests on real hardware or in some other
> +emulation environment, all you need to do is to take your kunitconfig, your
> +Kconfig options for the tests you would like to run, and merge them into
> +whatever config your are using for your platform. That's it!
> For example, let's say you have the following kunitconfig:
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4000 bytes --]
next prev parent reply other threads:[~2021-05-15 8:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-07 21:31 [PATCH v1 0/4] kunit: tool: add support for QEMU Brendan Higgins
2021-05-07 21:31 ` [PATCH v1 1/4] kunit: Add 'kunit_shutdown' option Brendan Higgins
2021-05-15 7:58 ` David Gow
2021-05-18 20:52 ` Brendan Higgins
2021-05-07 21:31 ` [PATCH v1 2/4] Documentation: Add kunit_shutdown to kernel-parameters.txt Brendan Higgins
2021-05-15 7:58 ` David Gow
2021-05-07 21:31 ` [PATCH v1 3/4] kunit: tool: add support for QEMU Brendan Higgins
2021-05-15 7:59 ` David Gow
2021-05-18 3:01 ` David Gow
2021-05-18 20:43 ` Brendan Higgins
2021-05-21 3:53 ` David Gow
2021-05-21 20:57 ` Brendan Higgins
2021-05-18 20:27 ` Brendan Higgins
2021-05-07 21:31 ` [PATCH v1 4/4] Documentation: kunit: document support for QEMU in kunit_tool Brendan Higgins
2021-05-15 8:01 ` David Gow [this message]
2021-05-18 21:08 ` Brendan Higgins
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.