Message-ID: <7f85416e-6e79-491c-902b-df6146928ff9@linuxfoundation.org>
Date: Tue, 30 Jul 2024 16:53:13 -0600
From: Shuah Khan <skhan@...uxfoundation.org>
To: David Gow <davidgow@...gle.com>
Cc: Muhammad Usama Anjum <usama.anjum@...labora.com>,
 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>,
 Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: Converting kselftest test modules to kunit

On 7/29/24 23:23, David Gow wrote:
> On Sat, 27 Jul 2024 at 03:35, Shuah Khan <skhan@...uxfoundation.org> wrote:
>>
>> On 7/15/24 04:09, 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
>>>
>>> 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/
>>>
>>
>> Please make sure you aren't taking away the ability to run these tests during
>> boot. It doesn't make sense to convert every single test especially when it
>> is intended to be run during boot without dependencies - not as a kunit test
>> but a regression test during boot.
> 
> Given KUnit tests can run at boot (and, indeed, do by default if
> enabled), I'd've assumed that this would be a good candidate for such
> a conversion. It does add the KUnit 'dependency', but I can't think of
> how that could be a problem. Is there a specific situation where
> enabling CONFIG_KUNIT would cause problems?
> 
>> bitmap is one example - pay attention to the config help test - bitmap
>> one clearly states it runs regression testing during boot. Any test that
>> says that isn't a candidate for conversion.
> 
> Again, most KUnit tests are effectively regression tests at boot, so I
> don't really understand what makes bitmap different. If it's just a
> matter of there being a different interface to it, that's surely
> something that we'll either be able to adapt to, or to have some
> wrapper/shim to maintain compatibility. I agree that having needless
> churn in formats is bad, but KUnit does seem the proper place for
> these sorts of tests.
> 

The problem is whether not kunit can test at boot time. The issue is
that this type of change removes a selftest which can be run without
kunit dependency thereby removing the ability to run these tests on
a running system without kunit.

This is absolutely necessary for testing on a running system to debug
or sopt check.

> If this isn't the case, do we need to modify the testing guide to
> mention this, as it definitely suggests KUnit for tests of in-kernel
> functionality like this.
> 

Please do. It was never the intent to convert all existing tests toi
kunit.

Repeating what I said on the bitmap removal thread:

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?

2. Leave kselftests alone so we don't weaken kernel testing by
    removing existing ones and making them dependent on kunit
    thereby removing the existing ability to be able run them on
    non-kunit kernels.


It isn't about kunit vs. kselftest. It is about overall kernel validation
and ability to test effectively by developers and users.

KUnit isn't ideal for cases where people would want to check a subsystem
on a running kernel - KUnit covers some use-cases and kselftest covers
others.

What happens if we are debugging a problem that requires us to debug on
a running system? Please don't go converting kselftest into kunit without
understanding how these frameworks are intended to be used.

Yes kselftest results need to be looked at. Write a parser which can
be improved. What you are doing is reducing the coverage and talking
away the ability to debug and test on running system.

Fix what needs to be fixed instead of deleting tests.

Think through the use-cases before advocating KUnit is suitable for
all testing needs and talking about being able to force or not force
people to use one or the other.

Reports aren't everything. The primary reason we have these tests is for
developers to be able to test. Reports can be improved and shouldn't
come at the expense of coverage and testing. Any patch that does that
will be NACKed.

I already nacked several patches and will continue to nack. Please don't
send me patches that remove existing kselftest tests and turn them into
kunit tests.

thanks,
-- Shuah

Powered by blists - more mailing lists