From: John Hubbard <jhubbard@nvidia.com>
To: Shuah Khan <skhan@linuxfoundation.org>,
David Gow <davidgow@google.com>,
Randy Dunlap <rdunlap@infradead.org>,
kees@kernel.org, Muhammad Usama Anjum <usama.anjum@collabora.com>
Cc: Yury Norov <yury.norov@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@collabora.com
Subject: Re: [PATCH 2/3] bitmap: Rename module
Date: Tue, 30 Jul 2024 11:44:14 -0700 [thread overview]
Message-ID: <504beb91-f0a3-47f4-8d68-d62577bb17d1@nvidia.com> (raw)
In-Reply-To: <75a2960e-d489-4440-a8e1-487a7f84902e@linuxfoundation.org>
On 7/30/24 11:17 AM, Shuah Khan wrote:
> On 7/30/24 09:55, Shuah Khan wrote:
>> On 7/30/24 04:10, David Gow wrote:
>>> On Mon, 29 Jul 2024 at 22:09, Randy Dunlap <rdunlap@infradead.org>
...
>>> I can see the point that renaming the config option is just churn, but
>>> is there a reason people would run the bitmap selftest but be unable
>>> or unwilling to use KUnit?
>>>
>>> Beyond a brief period of adjustment (which could probably be made
>>> quite minimal with a wrapper script or something), there shouldn't
>>> really be any fundamental difference: KUnit tests can already run at
>>> boot, be configured with a config option, and write output to the
>>> kernel log. There's nothing really being taken away here, and the
>>> bonus of having easier access to run the tests with KUnit's tooling
>>> (or have them automatically run by systems which run KUnit tests)
>>> would seem worthwhile to me, especially since it's optional. And
>>> CONFIG_KUNIT shouldn't be heavy enough to cause problems.
>>>
>
> Shouldn't be is the operative word? This doesn't help people who
> want run a run bitmap test on a running system. This is a wrong
> direction to go to say all testing has to be done under kunit.
>
> What happened to the effort to run selftests as is under KUnit? What
> is the motivation to convert all tests to kunit instead of trying to
> provide support to run kselftest under kunit environment?
>
> We discussed this a few years ago as I recall. Let's work on that
> instead of removing existing selftests and regressing current use-cases?
>
> Can we look into providing:
>
> 1. running kselftest under kunit environment without changes
> as user space applications?
Yes. I suggested this earlier: if something fits neatly into
a KUnit test, then with some additional work, it can also be
run from kselftest. Just supporting both would be very nice,
because people don't have to change anything about their testing
flow.
> 2. Leave kselftests alone so we don't weaken kernel testing
Or augment them as above, so that we don't weaken kernel testing,
yes.
thanks,
--
John Hubbard
NVIDIA
next prev parent reply other threads:[~2024-07-30 18:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-26 11:06 [PATCH 0/3] bitmap: Convert test_bitmap to kunit test Muhammad Usama Anjum
2024-07-26 11:06 ` [PATCH 1/3] bitmap: convert test_bitmap to KUnit test Muhammad Usama Anjum
2024-07-26 11:06 ` [PATCH 2/3] bitmap: Rename module Muhammad Usama Anjum
2024-07-26 18:45 ` John Hubbard
2024-07-29 7:57 ` Muhammad Usama Anjum
2024-07-26 19:24 ` Shuah Khan
2024-07-29 8:02 ` Muhammad Usama Anjum
2024-07-27 17:35 ` Yury Norov
2024-07-29 8:07 ` Muhammad Usama Anjum
2024-07-29 14:09 ` Randy Dunlap
2024-07-30 7:51 ` Muhammad Usama Anjum
2024-07-30 13:53 ` Randy Dunlap
2024-07-30 10:10 ` David Gow
2024-07-30 15:55 ` Shuah Khan
2024-07-30 18:17 ` Shuah Khan
2024-07-30 18:44 ` John Hubbard [this message]
2024-07-30 17:49 ` Yury Norov
2024-07-26 11:06 ` [PATCH 3/3] selftests: lib: remove test_bitmap Muhammad Usama Anjum
2024-07-26 19:22 ` Shuah Khan
2024-07-26 19:26 ` [PATCH 0/3] bitmap: Convert test_bitmap to kunit test Shuah Khan
2024-07-27 18:10 ` Yury Norov
2024-07-29 8:15 ` Muhammad Usama Anjum
2024-07-30 15:39 ` Shuah Khan
2024-07-31 3:05 ` David Gow
2024-07-29 8:29 ` Muhammad Usama Anjum
2024-07-30 15:49 ` Shuah Khan
2024-07-31 3:06 ` David Gow
2024-07-31 16:26 ` 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=504beb91-f0a3-47f4-8d68-d62577bb17d1@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=davidgow@google.com \
--cc=kees@kernel.org \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=rdunlap@infradead.org \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=usama.anjum@collabora.com \
--cc=yury.norov@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox