From: Kees Cook <kees@kernel.org>
To: Muhammad Usama Anjum <usama.anjum@collabora.com>
Cc: Shuah Khan <shuah@kernel.org>,
davidgow@google.com,
"open list : KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
kunit-dev@googlegroups.com,
"kernel@collabora.com" <kernel@collabora.com>
Subject: Re: Converting kselftest test modules to kunit
Date: Tue, 16 Jul 2024 10:59:06 -0700 [thread overview]
Message-ID: <202407161005.CACE2E355@keescook> (raw)
In-Reply-To: <8412a936-b202-4313-b5b4-ce6e72a3392f@collabora.com>
On Tue, Jul 16, 2024 at 01:11:14PM +0500, Muhammad Usama Anjum wrote:
> On 7/15/24 9:40 PM, Kees Cook wrote:
> > On Mon, Jul 15, 2024 at 03:09:24PM +0500, Muhammad Usama Anjum 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
> >
> > I would say this is a reasonable guide to how these things should
> > be separated, yes. That said, much of what was kind of ad-hoc kernel
> > internals testing that was triggered via kselftests is better done via
> > KUnit these days, but not everything.
> I started investigated when I found that kselftest doesn't parse the kernel
> logs to mark these tests pass/fail. (kselftest/lib is good example of it)
>
> >
> >> This brings me to conclusion that kselftest which are loading modules to
> >> test kernelspace should be converted to kunit tests. I've noted several
> >> such kselftests.
> >
> > I would tend to agree, yes. Which stand out to you? I've mainly been
> > doing the conversions when I find myself wanting to add new tests, etc.
> lib
> test_bitmap
> prime_numbers
> test_printf
> test_scanf
Yeah, these would be nice to convert.
> test_strscpy (already converted, need to remove this test)
Yup, converted in bb8d9b742aa7 ("string: Merge strscpy KUnit tests into string_kunit.c")
> lock
> test-ww_mutex module
> net
> test_blackhole_dev
I don't know these very well, but yeah worth looking into.
> user
> test_user_copy (probably already converted, need to remove this test)
This is done in -next via cf6219ee889f ("usercopy: Convert test_user_copy to KUnit test")
> firmware
> test_firmware
This might not work to convert: there's a userspace half for testing
firmware loading (see the kselftest side...)
> fpu
> test_fpu
Seems reasonable.
> Most of these modules are found in lib/*.
>
> Would it be desired to move these to kunit?
Checking with the authors/maintainer is probably the first thing to do;
check the git history to see who has been working on them.
--
Kees Cook
next prev parent reply other threads:[~2024-07-16 17:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 10:09 Converting kselftest test modules to kunit Muhammad Usama Anjum
2024-07-15 16:40 ` Kees Cook
2024-07-16 8:11 ` Muhammad Usama Anjum
2024-07-16 17:59 ` Kees Cook [this message]
2024-07-16 18:04 ` John Hubbard
2024-07-16 18:26 ` Kees Cook
2024-07-17 21:11 ` John Hubbard
2024-07-17 10:55 ` Muhammad Usama Anjum
2024-07-16 7:33 ` David Gow
2024-07-17 10:47 ` Muhammad Usama Anjum
2024-07-17 21:44 ` John Hubbard
2024-07-26 19:35 ` Shuah Khan
2024-07-29 7:55 ` Muhammad Usama Anjum
2024-07-30 22:55 ` Shuah Khan
2024-07-30 5:23 ` David Gow
2024-07-30 22:53 ` Shuah Khan
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202407161005.CACE2E355@keescook \
--to=kees@kernel.org \
--cc=davidgow@google.com \
--cc=kernel@collabora.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=usama.anjum@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.