linux-kernel - Re: Converting kselftest test modules to kunit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABVgOSmD6j2OK1WXXcO+fTRN7PSpMFph8BT3Unko0c+Bv+3bjA@mail.gmail.com>
Date: Tue, 16 Jul 2024 15:33:51 +0800
From: David Gow <davidgow@...gle.com>
To: Muhammad Usama Anjum <usama.anjum@...labora.com>
Cc: Kees Cook <keescook@...omium.org>, Shuah Khan <shuah@...nel.org>, 
	"open list : KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>, 
	kunit-dev@...glegroups.com, "kernel@...labora.com" <kernel@...labora.com>
Subject: Re: Converting kselftest test modules to kunit

On Mon, 15 Jul 2024 at 18:09, Muhammad Usama Anjum
<usama.anjum@...labora.com> wrote:
>
> Hi Kees and All,
>
> There are several tests in kselftest subsystem which load modules to tests
> the internals of the kernel. Most of these test modules are just loaded by
> the kselftest, their status isn't read and reported to the user logs. Hence
> they don't provide benefit of executing those tests.
>
> I've found patches from Kees where he has been converting such kselftests
> to kunit tests [1]. The probable motivation is to move tests output of
> kselftest subsystem which only triggers tests without correctly reporting
> the results. On the other hand, kunit is there to test the kernel's
> internal functions which can't be done by userspace.
>
> Kselftest:      Test user facing APIs from userspace
> Kunit:          Test kernel's internal functions from kernelspace

Yes: this is how we'd like to split things up. There are still a few
cases where you might want to use kselftest to test something other
than a user-facing API (if you needed to set up some complicated
userspace structures, etc), or cases where KUnit might be used to test
something other than individual pieces of functionality, but that
categorisation is a good start.

The Documentation/dev-tools/testing-overview.rst page has a more
detailed look at when to use which test framework (which basically
just repeats those rules):
https://docs.kernel.org/dev-tools/testing-overview.html

Cheers,
-- David

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4014 bytes)