[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250620152344-fadbb8ae-0a86-4938-b05d-00da66fc05c5@linutronix.de>
Date: Fri, 20 Jun 2025 15:43:44 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: David Gow <davidgow@...gle.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
Nathan Chancellor <nathan@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>,
Willy Tarreau <w@....eu>, Thomas Weißschuh <linux@...ssschuh.net>,
Brendan Higgins <brendan.higgins@...ux.dev>, Rae Moar <rmoar@...gle.com>, Shuah Khan <shuah@...nel.org>,
Jonathan Corbet <corbet@....net>, Nicolas Schier <nicolas.schier@...ux.dev>,
Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
Christophe Leroy <christophe.leroy@...roup.eu>, linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com, linux-doc@...r.kernel.org,
linux-riscv@...ts.infradead.org, workflows@...r.kernel.org
Subject: Re: [PATCH v3 13/16] kunit: Introduce UAPI testing framework
On Fri, Jun 20, 2025 at 05:47:39PM +0800, David Gow wrote:
> On Wed, 11 Jun 2025 at 15:38, Thomas Weißschuh
> <thomas.weissschuh@...utronix.de> wrote:
> >
> > Enable running UAPI tests as part of kunit.
> > The selftests are embedded into the kernel image and their output is
> > forwarded to kunit for unified reporting.
> >
> > The implementation reuses parts of usermode drivers and usermode
> > helpers. However these frameworks are not used directly as they make it
> > impossible to retrieve a thread's exit code.
> >
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> >
> > ---
>
> It feels to me like there are three features hidden in here:
> - KUnit helpers for manipulating vfs files
> - A way of having KUnit tests run userspace helpers
> - The full framework for writing/running whole tests in userspace.
>
> It's really the first two which excite me personally most -- as they
> give us a sort-of inverse to the kselftest "helper module" paradigm --
> so we can test things which are impossible to test from within
> kernelspace.
For me it is only the third feature that I really care about right now.
But I do expect users for the first two to pop up at some point and these are
obviously valid usecases.
> So maybe those APIs should be exposed separately (so a
> test can be written mostly in kernel-space using the KUnit framework
> APIs, and just call out to a helper where needed). But I'm happy for
> them to stay private functions until we have a test which actually
> needs them.
Agreed, let's expose it when there are users.
> > Currently this depends on CONFIG_KUNIT=y as it uses some non-exported
> > symbols around process management.
>
> That's fine for now, IMHO, but will make it difficult to use this on,
> e.g., Red Hat setups, where CONFIG_KUNIT=m. Hopefully we can resolve
> this by exporting some of the symbols?
I'll try to use the new EXPORT_SYMBOL_GPL_FOR_MODULES() on these symbols and
see what the maintainers say about it.
> In general, I'm happy with the implementation here. The fs stuff
> probably needs a closer look from someone who knows the vfs better
> than me, though.
>
> Nevertheless,
> Reviewed-by: David Gow <davidgow@...gle.com>
Thanks
>
> Cheers,
> -- David
>
> > ---
> > Documentation/dev-tools/kunit/api/index.rst | 5 +
> > Documentation/dev-tools/kunit/api/uapi.rst | 12 ++
> > include/kunit/uapi.h | 24 +++
> > lib/kunit/Kconfig | 10 +
> > lib/kunit/Makefile | 2 +
> > lib/kunit/uapi.c | 287 ++++++++++++++++++++++++++++
> > 6 files changed, 340 insertions(+)
<snip>
Powered by blists - more mailing lists