linux-kernel - Re: Converting kselftest test modules to kunit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5d31907f-1ba0-49ad-968d-52991d3268b3@nvidia.com>
Date: Wed, 17 Jul 2024 14:44:11 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Muhammad Usama Anjum <usama.anjum@...labora.com>, David Gow
	<davidgow@...gle.com>
CC: 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>
Subject: Re: Converting kselftest test modules to kunit

On 7/17/24 3:47 AM, Muhammad Usama Anjum wrote:
> Hi David,
> 
> On 7/16/24 12:33 PM, David Gow wrote:
>> On Mon, 15 Jul 2024 at 18:09, Muhammad Usama Anjum
>> <usama.anjum@...labora.com> 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
>>
>> Yes: this is how we'd like to split things up. There are still a few

Me too. It works.

>> cases where you might want to use kselftest to test something other
>> than a user-facing API (if you needed to set up some complicated
>> userspace structures, etc), or cases where KUnit might be used to test
>> something other than individual pieces of functionality, but that
>> categorisation is a good start.
> Yeah, makes sense. It is helpful to find out what others think. I'll be
> back with changes.
> 

At some point we could connect up the two systems, without really
changing any of the guidelines...much. One way to do that would
be to add a tiny bit of kselftest support for easily launching
a kunit baremetal testing, and then reading the results (which
are right there in sysfs) back to user space.

So it would look like a kselftest, but it could run any kernel-based
tests it needs via kunit.

And the two systems can still be used independently.

>>
>> The Documentation/dev-tools/testing-overview.rst page has a more
>> detailed look at when to use which test framework (which basically
>> just repeats those rules):
>> https://docs.kernel.org/dev-tools/testing-overview.html

Yes, a nice example of up-to-date documentation there. And it's
very clear.

>>
>> Cheers,
>> -- David
> 

thanks,
-- 
John Hubbard
NVIDIA