[PATCH] kunit: tool: show list of valid --arch options when invalid

0 views
Skip to first unread message

Daniel Latypov

unread,
Sep 29, 2021, 7:26:00 PM9/29/21
to brendan...@google.com, davi...@google.com, linux-...@vger.kernel.org, kuni...@googlegroups.com, linux-k...@vger.kernel.org, sk...@linuxfoundation.org, Daniel Latypov
Consider this attempt to run KUnit in QEMU:
$ ./tools/testing/kunit/kunit.py run --arch=x86

Before you'd get this error message:
kunit_kernel.ConfigError: x86 is not a valid arch

After:
kunit_kernel.ConfigError: x86 is not a valid arch, options are ['alpha', 'arm', 'arm64', 'i386', 'powerpc', 'riscv', 's390', 'sparc', 'x86_64']

This should make it a bit easier for people to notice when they make
typos, etc. Currently, one would have to dive into the python code to
figure out what the valid set is.

Signed-off-by: Daniel Latypov <dlat...@google.com>
---
tools/testing/kunit/kunit_kernel.py | 5 +++--
tools/testing/kunit/kunit_tool_test.py | 4 ++++
2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py
index 1870e75ff153..a6b3cee3f0d0 100644
--- a/tools/testing/kunit/kunit_kernel.py
+++ b/tools/testing/kunit/kunit_kernel.py
@@ -198,8 +198,9 @@ def get_source_tree_ops(arch: str, cross_compile: Optional[str]) -> LinuxSourceT
return LinuxSourceTreeOperationsUml(cross_compile=cross_compile)
elif os.path.isfile(config_path):
return get_source_tree_ops_from_qemu_config(config_path, cross_compile)[1]
- else:
- raise ConfigError(arch + ' is not a valid arch')
+
+ options = [f[:-3] for f in os.listdir(QEMU_CONFIGS_DIR) if f.endswith('.py')]
+ raise ConfigError(arch + ' is not a valid arch, options are ' + str(sorted(options)))

def get_source_tree_ops_from_qemu_config(config_path: str,
cross_compile: Optional[str]) -> Tuple[
diff --git a/tools/testing/kunit/kunit_tool_test.py b/tools/testing/kunit/kunit_tool_test.py
index cad37a98e599..2ae72f04cbe0 100755
--- a/tools/testing/kunit/kunit_tool_test.py
+++ b/tools/testing/kunit/kunit_tool_test.py
@@ -289,6 +289,10 @@ class LinuxSourceTreeTest(unittest.TestCase):
pass
kunit_kernel.LinuxSourceTree('', kunitconfig_path=dir)

+ def test_invalid_arch(self):
+ with self.assertRaisesRegex(kunit_kernel.ConfigError, 'not a valid arch, options are.*x86_64'):
+ kunit_kernel.LinuxSourceTree('', arch='invalid')
+
# TODO: add more test cases.



base-commit: 865a0a8025ee0b54d1cc74834c57197d184a441e
--
2.33.0.685.g46640cef36-goog

David Gow

unread,
Sep 29, 2021, 8:23:35 PM9/29/21
to Daniel Latypov, Brendan Higgins, Linux Kernel Mailing List, KUnit Development, open list:KERNEL SELFTEST FRAMEWORK, Shuah Khan
On Thu, Sep 30, 2021 at 7:26 AM Daniel Latypov <dlat...@google.com> wrote:
>
> Consider this attempt to run KUnit in QEMU:
> $ ./tools/testing/kunit/kunit.py run --arch=x86
>
> Before you'd get this error message:
> kunit_kernel.ConfigError: x86 is not a valid arch
>
> After:
> kunit_kernel.ConfigError: x86 is not a valid arch, options are ['alpha', 'arm', 'arm64', 'i386', 'powerpc', 'riscv', 's390', 'sparc', 'x86_64']
>
> This should make it a bit easier for people to notice when they make
> typos, etc. Currently, one would have to dive into the python code to
> figure out what the valid set is.
>
> Signed-off-by: Daniel Latypov <dlat...@google.com>
> ---

This is really nice, particularly given that we've had to reproduce
that list in lots of talks, documentation, etc. and it could get
out-of-date.

Reviewed-by: David Gow <davi...@google.com>

[FYI: this didn't seem to apply cleanly to kselftest/kunit head, but
it was a pretty minor issue with kunit_tool_test.py.]

Thanks,
-- David

Daniel Latypov

unread,
Sep 29, 2021, 8:31:31 PM9/29/21
to David Gow, Brendan Higgins, Linux Kernel Mailing List, KUnit Development, open list:KERNEL SELFTEST FRAMEWORK, Shuah Khan
On Wed, Sep 29, 2021 at 5:23 PM David Gow <davi...@google.com> wrote:
>
> On Thu, Sep 30, 2021 at 7:26 AM Daniel Latypov <dlat...@google.com> wrote:
> >
> > Consider this attempt to run KUnit in QEMU:
> > $ ./tools/testing/kunit/kunit.py run --arch=x86
> >
> > Before you'd get this error message:
> > kunit_kernel.ConfigError: x86 is not a valid arch
> >
> > After:
> > kunit_kernel.ConfigError: x86 is not a valid arch, options are ['alpha', 'arm', 'arm64', 'i386', 'powerpc', 'riscv', 's390', 'sparc', 'x86_64']
> >
> > This should make it a bit easier for people to notice when they make
> > typos, etc. Currently, one would have to dive into the python code to
> > figure out what the valid set is.
> >
> > Signed-off-by: Daniel Latypov <dlat...@google.com>
> > ---
>
> This is really nice, particularly given that we've had to reproduce
> that list in lots of talks, documentation, etc. and it could get
> out-of-date.
>
> Reviewed-by: David Gow <davi...@google.com>
>
> [FYI: this didn't seem to apply cleanly to kselftest/kunit head, but
> it was a pretty minor issue with kunit_tool_test.py.]

Oh, this is on top of
https://lore.kernel.org/linux-kselftest/20210928221111.1...@google.com/

I guess this line there
- tree = kunit_kernel.LinuxSourceTree('', kunitconfig_path=dir)
+ kunit_kernel.LinuxSourceTree('', kunitconfig_path=dir)
tripped things up a bit.

Brendan Higgins

unread,
Oct 5, 2021, 5:27:58 PM10/5/21
to Daniel Latypov, davi...@google.com, linux-...@vger.kernel.org, kuni...@googlegroups.com, linux-k...@vger.kernel.org, sk...@linuxfoundation.org
On Wed, Sep 29, 2021 at 4:26 PM Daniel Latypov <dlat...@google.com> wrote:
>
> Consider this attempt to run KUnit in QEMU:
> $ ./tools/testing/kunit/kunit.py run --arch=x86
>
> Before you'd get this error message:
> kunit_kernel.ConfigError: x86 is not a valid arch
>
> After:
> kunit_kernel.ConfigError: x86 is not a valid arch, options are ['alpha', 'arm', 'arm64', 'i386', 'powerpc', 'riscv', 's390', 'sparc', 'x86_64']
>
> This should make it a bit easier for people to notice when they make
> typos, etc. Currently, one would have to dive into the python code to
> figure out what the valid set is.
>
> Signed-off-by: Daniel Latypov <dlat...@google.com>

Yes! Thank you for fixing this!

Reviewed-by: Brendan Higgins <brendan...@google.com>
Reply all
Reply to author
Forward
0 new messages