From: Brendan Higgins <firstname.lastname@example.org>
To: David Gow <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: Tue, 18 May 2021 14:08:43 -0700 [thread overview]
Message-ID: <CAFd5g47dqGin2QO_RLZKu93rt_j0xv7Dg1KTCrgYi7bVoaEjKg@mail.gmail.com> (raw)
On Sat, May 15, 2021 at 1:01 AM David Gow <email@example.com> wrote:
> On Sat, May 8, 2021 at 5:31 AM Brendan Higgins
> <firstname.lastname@example.org> wrote:
> > 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.
> -- David
> > 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.
Cool, I will fix that in the next revision.
> > 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
> documented there.
Probably a good idea. However, I will ask Shuah to pick up the
Documentation changes before I document the new options to avoid
> > +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:
> > --
> > 18.104.22.1687.g51e8a6a459-goog
prev parent reply other threads:[~2021-05-18 21:08 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
2021-05-18 21:08 ` Brendan Higgins [this message]
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.