[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230608104828.38797-1-falcon@tinylab.org>
Date: Thu, 8 Jun 2023 18:48:28 +0800
From: Zhangjin Wu <falcon@...ylab.org>
To: thomas@...ch.de
Cc: falcon@...ylab.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, w@....eu
Subject: nolibc: KTAP output and test reports
Hi, Thomas
> Hi Willy, Zhangjin,
>
> after your recent discussions about the test output and report I
> wondered if it would make sense to switch nolibc-test to KTAP output
> format [0].
Just read the doc, it looks really good.
>
> With this it would be possible to have a wrapper script run each
> architecture test as its own test subcomponent.
> A (K)TAP parser/runner could then directly recognize and report failing
> testcases, making it easier to validate.
>
Yeah, this is what can we benefit from the standard format.
> Also maybe we can hook it up into the regular kselftests setup and have
> the bots run it as part of that.
>
I did take a look at the other kselftests cases, seems lots of cases use
qemu to run the tests, perhaps we can share some of them. Not sure if
there are some libraries work on qemu test support, therefore, we can
reuse them.
> The kernel even includes a header-only library to implement the format [1].
> It also should be fairly easy to emit the format without a library.
>
Perhaps we can learn and discuss on how to use them at first, I'm a newbie to
both of them, but I'm really interested in running nolibc in the kselftest
framework ;-)
Thanks,
Zhangjin
> Thomas
>
> [0] Documentation/dev-tools/ktap.rst
> [1] Documentation/dev-tools/kselftest.rst (Test harness)
Powered by blists - more mailing lists