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
