From User to Contributor: My Linux Kernel Mentorship Journey
Linux has been a part of my journey for several years, starting with the day I installed my first Linux distribution, Ubuntu, on my HP laptop. Since then, I have used various distributions such as Fedora, Manjaro, and Linux Mint. While the user experience may differ across these distributions, they all share the same foundation: the Linux Kernel. This made me curious about how the kernel itself is developed and gave me a interest in contributing to it.
Although I was familiar with programming, Linux, and Git, contributing to the kernel seemed very different from working on a typical software project. I did not know where to start, how to read kernel codebase, how to find suitable issues or send patches upstream.
I came across the Linux Kernel Mentorship Program while exploring various opportunities on the LFX Mentorship Portal. The program immediately stood out to me because it offered an opportunity to learn the kernel development process from experienced maintainers and developers while making real contributions to the project. I saw it as the right starting point to turn my interest in the Linux Kernel into actual upstream contributions.
Application Process
First, I created a mentee profile on the LFX mentorship portal.
LKMP offers two mentorship terms each year, and I applied for the Spring 2026 term.
As soon as I applied, I was assigned multiple tasks as prerequisites for the application. These include completing the LFD 103 course on the Linux Foundation portal (A Beginner’s Guide to Linux Kernel Development) and uploading the course completion certificate, writing detailed answers to the given questions, building the latest kernel release, sending a sample patch and submitting my resume and cover letter.
I completed all the tasks before their respective deadlines.
After completing all the requirements, I received the acceptance email from LFX two weeks later!
Getting started
All the mentees were invited to join a Discord server where people could post their questions and mentors and peers could help them resolve their issues. Along with that, my mentors, Shuah Khan and Brigham Campbell, organized weekly office hours where we could ask questions, get our patches reviewed, and understand how the kernel community functions through the mailing lists.
During the first office hour session, I met my fellow mentees. Some were already contributing to the Linux kernel, while others were absolute beginners like me. I still remember taking notes so that I could refer back to the important points while working on patches :)
We were introduced to different tools that could help us explore the kernel tree and identify issues:
Navigation & Formatting: Cscope, Codespell
Static Analysis: Coccinelle, Smatch
Testing & Fuzzing: QEMU, GDB, Syzkaller, Syzbot
I was overwhelmed by the sheer size of the kernel codebase. The mentors advised us that it was not necessary to understand the entire codebase before making contributions. We were asked to pick any two subsystems of our choice so that we could focus on those areas while looking for opportunities to contribute.
Initially, I spent most of my time exploring the codebase, understanding the structure of different drivers, reading Device Tree bindings and documentation, and going through the mailing lists to see what previous mentees had worked on and what my fellow mentees were currently working on.
Contribution and Learnings
As this was my first time contributing to the Linux kernel, I started by finding and fixing spelling errors in the documentation. Codespell helped me identify typos, and I also fixed multiple dead hyperlinks by replacing them with working links. These contributions helped me get familiar with the patch submission and review process and boosted my confidence to look for new issues to work on. I still remember spending around an hour cross-checking everything before sending my first patch to the mailing lists.
Next, I moved on to converting text-based Device Tree bindings to the newer JSON Schema format. This was my first significant contribution after working on small typo and dead-link fixes. Various resources helped me develop a basic understanding of how bindings are written and the rules for converting them to JSON Schema. Some of the resources I found useful were:
https://docs.kernel.org/devicetree/index.html#devicetree-bindings
And most importantly, I used existing Device Tree bindings from the respective subsystems as references when converting the other bindings.
For these patches, I received helpful feedback from reviewers and maintainers and incorporated their suggestions into subsequent versions. I submitted Device Tree binding conversion patches for the LED, regulator, and SPI subsystems. Working through multiple revisions taught me how to interpret review comments and improve a patch based on maintainer feedback.
Moving forward, I used Coccinelle to identify outdated coding patterns in the kernel code. I found and fixed issues in two drivers: mcp16502 in the regulator subsystem and bcm63138 in the LED subsystem. In the mcp16502 driver, I replaced the older dev_err() API with dev_err_probe() for error paths that can return -EPROBE_DEFER. This avoids unnecessary error messages when probe deferral is expected. In the bcm63138 driver, I improved error reporting by replacing %ld with %pe and passing the error pointer directly, allowing the kernel to print the symbolic error name.
In total, 11 of my patches were merged into the Linux kernel mainline. Throughout the mentorship program, my mentors helped me understand and interpret maintainer feedback and taught me how to communicate clearly on the mailing list. Seeing the work of my fellow mentees also gave me ideas about potential areas to explore and motivated me to work on more meaningful contributions and continuously improve my patches.
Tips for first-time contributors
Always run the kernel workflow scripts (
get_maintainers.pl,checkpatch.pl), compile your changes, and test your patches before sending them to the mailing lists. Make sure you are sending them to all relevant maintainers and mailing lists.Work on multiple patches in parallel rather than sequentially. Start exploring your next contribution as soon as you have sent your previous patch for review.
Carefully read and understand the feedback and issues reported by reviewers and maintainers, and send updated versions of your patches promptly.
Watch the LF Live Mentorship Series to get a basic understanding of the tools used in kernel development and how to identify potential issues.
Starting with small spelling and documentation fixes is a good way to get familiar with the contribution process, but don't stop there. Use them to learn the submission and review workflow, and gradually move towards patches that fix real problems or improve kernel functionality.
Before finding and fixing issues in a subsystem, spend some time reading its documentation, code, existing patches, and recent discussions on the mailing list. Understanding the subsystem's conventions and how maintainers expect patches to be written can save you a lot of iteration later.
Finally
The Linux Kernel Mentorship Program was an excellent stepping stone for me to get started with upstream Linux Kernel contributions and begin my open-source journey. I would first like to thank my mentors, Shuah Khan and Brigham Campbell, for giving me this opportunity and mentoring me throughout the program.
As a first-time contributor, the first few weeks were overwhelming. However, as I spent more time exploring the kernel codebase, learning the tools, and reading other people's patches, I gradually developed a better understanding of the kernel development process. This helped me become more confident and enabled me to identify issues and work on patches independently. After the program, I plan to continue contributing to the kernel and working on fixing bugs and improving existing code.
If you have read this far and are interested in contributing to the Linux Kernel, I highly recommend applying to LKMP. It is a great opportunity to learn kernel development from experienced contributors, get familiar with the upstream workflow, and make your first contributions to one of the world's largest open-source projects.
