Re: First Contributions for KUnit

[David Gow]

On Mon, 20 May 2024 at 23:09, Artur A C de Barros <arturacb@xxxxxxxxx> wrote:
>
> 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 focuses on researching and contributing to open source software. Our group has organized kernel hackathons in the past [1] that resulted in sucessful contributions, 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 previous 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 suggestions of other code that could benefit from having KUnit tests.
>
> Thanks!
> Artur Alves
>
> [1] https://lore.kernel.org/dri-devel/20211011152333.gm5jkaog6b6nbv5w@notapiano/
>

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=767643