Received-SPF: pass (google.com: domain of linux-kernel+bounces-185939-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <Zktnt7rjKryTh9-N@arch>
In-Reply-To: <Zktnt7rjKryTh9-N@arch>
From: David Gow <davidgow@google.com>
Date: Wed, 22 May 2024 16:37:30 +0800
Message-ID: <CABVgOS=xA15qTL1Uqcxe6+uLubRHCLt5+me9ykV9_gOXhvXQtA@mail.gmail.com>
Subject: Re: First Contributions for KUnit
To: Artur A C de Barros <arturacb@gmail.com>
Cc: willy@infradead.org, linux-kselftest@vger.kernel.org, 
	kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org, 
	linux-fsdevel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 20 May 2024 at 23:09, Artur A C de Barros <arturacb@gmail.com> wrot=
e:
>
> Hi all,
>
> We are students from the State University of Campinas with an interest in=
 contributing to the kernel. We are part of LKCAMP, a student group that fo=
cuses on researching and contributing to open source software. Our group ha=
s organized kernel hackathons in the past [1] that resulted in sucessful co=
ntributions, and we would like to continue the effort this year.
>
> This time, we were thinking about writing KUnit tests for data structures=
 in `lib/` (or converting existing lib test code), similarly to our previou=
s hackathon. We are currently considering a few candidates:
>
> - lib/kfifo.c
> - lib/llist.c
> - tools/testing/scatterlist
> - tools/testing/radix-tree
>
> We would like to know if these are good candidates, and also ask for sugg=
estions of other code that could benefit from having KUnit tests.
>
> Thanks!
> Artur Alves
>
> [1] https://lore.kernel.org/dri-devel/20211011152333.gm5jkaog6b6nbv5w@not=
apiano/
>

Hi Artur,

Thanks for reaching out: the contributions from LKCAMP in the past
have been great, so we'd love to see more from you!

Data structures do tend to be an excellent starting point for new
contributors, so I think you're on the right track. As the maintainer
of the other linked list tests (lib/list_test.c), I think llist (and
probably also kfifo) could be great starts. I'm not very familiar with
the scatterlist and radix-tree code myself, but it could also be
useful.

Otherwise, a couple of suggestions would be:
- As you've already done, look for standalone files in lib/ or in the
headers (include/). There are almost certainly more self-contained
data structures to work with.
- The FAT filesystem (fs/fat/) has some basic tests, but could use
some more advanced ones using the KUnit function redirection features.
This would be more complicated than simple data-structure work, but
could be interesting.
- Otherwise, lots of other drivers, filesystems, subsystems, etc will
have need of tests. The tricky bit is that you'll need to have some
way of stubbing/mocking out their interactions with actual hardware
and the rest of the kernel.
- If you've got anyone who's an expert in Rust, some of the KUnit rust
bindings[1] could use reworking. if you want to work on test
infrastructure as well as the tests themselved.

I'm sure there are other people on the list with more suggestions:
there's a lot of room for more tests in the kernel, after all!

Cheers,
-- David

[1]: https://patchwork.kernel.org/project/linux-kselftest/list/?series=3D76=
7643