From: Muhammad Usama Anjum <usama.anjum@collabora.com>
To: Kees Cook <keescook@chromium.org>, Shuah Khan <shuah@kernel.org>,
davidgow@google.com
Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>,
"open list : KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
kunit-dev@googlegroups.com, David Gow <davidgow@google.com>,
"kernel@collabora.com" <kernel@collabora.com>
Subject: Converting kselftest test modules to kunit
Date: Mon, 15 Jul 2024 15:09:24 +0500 [thread overview]
Message-ID: <327831fb-47ab-4555-8f0b-19a8dbcaacd7@collabora.com> (raw)
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
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.
This is just my understanding. Please mention if I'm correct above or more
reasons to support kselftest test modules transformation into kunit test.
[1] https://lore.kernel.org/all/20221018082824.never.845-kees@kernel.org/
--
BR,
Muhammad Usama Anjum
next reply other threads:[~2024-07-15 10:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 10:09 Muhammad Usama Anjum [this message]
2024-07-15 16:40 ` Converting kselftest test modules to kunit Kees Cook
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=327831fb-47ab-4555-8f0b-19a8dbcaacd7@collabora.com \
--to=usama.anjum@collabora.com \
--cc=davidgow@google.com \
--cc=keescook@chromium.org \
--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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox