All of lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 15 Jul 2024 09:40:01 -0700	[thread overview]
Message-ID: <202407150936.C32FE24CA@keescook> (raw)
In-Reply-To: <327831fb-47ab-4555-8f0b-19a8dbcaacd7@collabora.com>

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.

> 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.

-- 
Kees Cook

  reply	other threads:[~2024-07-15 16:40 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 [this message]
2024-07-16  8:11   ` Muhammad Usama Anjum
2024-07-16 17:59     ` Kees Cook
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=202407150936.C32FE24CA@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.