GSoC Project Idea: Increase code coverage of the DRM code

Mentor: Maíra Canal Co-mentors: André Almeida, Tales Aparecida, Paulo Meirelles

Pre-requisites

For this project, all GSoC contributors must:

• have any Linux-based distro as their main system
• feel comfortable with the terminal and working with the Linux command-line
• have a moderate knowledge of C (e.g. working with pointers should not be an issue)
• be willing to participate on a public mailing list
• be able to work in a group and be willing to help other people
• fully complete the warm-up and first patch sections

Warm-up

This section is mandatory for everybody

If you are interested in this project, you must complete the following pre-requisites before you start your application:

• setup a virtual machine - https://flusp.ime.usp.br/kernel/use-qemu-to-play-with-linux/
• learn how to compile the Linux kernel - https://flusp.ime.usp.br/kernel/Kernel-compilation-and-installation/
• learn how to install and remove a Linux kernel - https://flusp.ime.usp.br/kernel/Kernel-compilation-and-installation/
• learn how to deal with modules - https://flusp.ime.usp.br/kernel/play_with_modules/
• learn how to use kw to speed-up your workflow - https://kworkflow.org/ and try to deploy a new kernel by using this tool (see the tutorial section)
• learn the basics about the Linux kernel contribution process; we recommend you to at least carefully read the following pages:
  • https://www.kernel.org/doc/html/latest/process/2.Process.html#development-process
  • https://www.kernel.org/doc/html/latest/process/submitting-patches.html#submittingpatches
• as a freedesktop.org project, dri-devel and the DRM community follow the Contributor Covenant, found at: https://www.freedesktop.org/wiki/CodeOfConduct
• subscribe to the dri-devel mailing-list and join the oftc#dri-devel channel on IRC

If you are not able to complete these steps, or did not have fun doing them, this project may not be a good fit for you.

First Patch

This section is mandatory for everybody

Now it is time for you to send your first set of contributions; for this part, you should send a single patch and a patchset (minimum of two patches in the patchset). You are free to send any patch to any kernel subsystem that you prefer; however, to increase your chance to get feedback and your change merged, we recommend the following:

1. For your first contribution, we recommend something simple but useful. For this reason, here is a list of potential contributions in order of importance:

   1. Compile your kernel with W=1, capture all kernel logs in a file, and try to fix them (try to make a real fix, not simply silencing the compilation warning).

   2. Compile the kernel documentation, take a look at all warnings and errors and try to fix some of them.

   3. Run kw codestyle and try to fix some of the issues. If you try this type of contribution, do not improve things blindly. Find a problem, understand it, evaluate if we really need it, and then make your patch. Please, try to be very critical of yourself if you try this type of contribution because many of the complaints generated by the kernel codestyle are ignored for a reason.

2. We recommend you use the drm-misc repository: https://gitlab.freedesktop.org/drm/misc/kernel. As it will be the repository you will be working with during the GSoC project.

3. You can focus on any part of the kernel that you want, but we recommend you to work on drivers/gpu/drm/ since we will work on these helpers during the GSoC project.

Project Idea

The main idea is to increase the test coverage of the DRM core helpers by adding more KUnit tests to it. KUnit is a lightweight unit testing and mocking framework for the Linux kernel.

At XDC 2022, Magali Lemes broke down the test coverage of the DRM core helpers https://www.youtube.com/watch?v=HvKf4bBz74o, and we can see that there are plenty of DRM helpers that are not fully covered yet. So, in the project, contributors will introduce more unit tests to the DRM core helpers.

For writing your project proposal, we recommend you to read the following links to learn more about this topic:

• https://en.wikipedia.org/wiki/Unit_testing

• https://docs.kernel.org/dev-tools/kunit/

• https://docs.kernel.org/gpu/introduction.html

• https://gitlab.freedesktop.org/drm/igt-gpu-tools

How To Prepare Your Project Proposal

The warm-up section is mandatory for everyone; for this reason, your final project proposal should have one section per assignment with two or three paragraphs that describe your experience with each task. Additionally, including screenshots demonstrating that you've completed those activities (e.g. showing your VM running with your custom kernel) is a plus.

Finally, make sure that you have the following sections in your application:

• Basic info about you (Name, preferred pronouns, GitLab or similar, your blog page, your website, email, and IRC nickname);

• One or two paragraphs about you;

• A section that describes how you achieved each of the warm-up pre-requisites;

• Sections that describe your interaction with the Linux kernel (your first patches);

• Add a section that describes your understanding of the project. We recommend you include something about KUnit and a basic overview of the DRM graphics stack;

• A section that breaks down how you plan to execute the project proposal while following the GSoC timeline. As previously mentioned, the project's primary goal is to introduce more KUnit tests to the DRM core helpers. Project proposals outside of this context will not be accepted. Although the scope of this project is well defined, contributors need to demonstrate they also understand their skills and boundaries. Therefore, contributors should build a project proposal based on their knowledge, acquired skills, as well as their own ideas. Besides that, make sure to add two main milestones (i.e. it should match the GSoC evaluation dates).

NOTE: Feel free to share your draft before submitting the final version. We'll be happy to give you feedback to improve and strengthen your proposal.