💡 Chapter 1: Origin Story
My path to the Linux Kernel started, fittingly, with breaking things. As a kid, I enjoyed tinkering with Windows—treating CCleaner like a religious ritual and constantly optimizing drivers. However, the true turning point came when I attempted to flash a custom ROM on my first Android phone.
I successfully executed a soft-brick within a month.
Stuck in my college hostel with a shiny, non-functional paperweight, I spent days debugging on XDA forums. That desperate effort to revive my phone is how I first encountered Linux. When I finally cracked the solution, the feeling of regaining control over the hardware was immense. I was hooked on the power of the OS layer.
Later, GSoC introduced me to the ownership and intensity of Open Source development. It was then I realized the Linux Kernel—the core of most servers and mobile devices—was also open source. My long-term goal became clear: to contribute to the Linux Kernel and earn my name in the source tree. This LFX mentorship was the first serious step toward that ambition.
🎒 Chapter 2: The Kernel Development Toolkit
Kernel development requires rigorous discipline and specialized tools. It’s a vast domain, so having a good, consolidated set of resources is critical.
Crucial Advice: I highly recommend going through 2 or 3 blogs rather than fixating on just one. Everyone has a slightly different journey, and you might find a workflow or approach that suits you better in another write-up.
⭐ The Ultimate Resource Index
I want to specifically highlight the Kernel Pocket Index. This resource is an exhaustive aggregation of everything related to Linux kernel development and should be supported by maintainers. I feel it is one of the best places to start.
https://hackmd.io/@0xff07/kernel-pocket-index#/
📚 Learning and Documentation
- Foundation: The LFD103 course is a mandatory and excellent starting point. Go through it thoroughly.
- Context: Review previous mentee blogs and mentorship session recordings on YouTube.
- Subsystem Focus: The kernel is huge. Start by studying specific subsystems you plan to contribute to. Use the Kernel Map for reference.
- Books: The list here is useful. I suggest using The Linux Programming Interface as a reference for specific concepts, as reading it cover-to-cover is incredibly exhaustive and often repetitive.
⚙️ Essential Kernel Tooling
The kernel community relies on the email-based patch submission workflow. These tools streamline that process:
| Tool/Resource | Purpose and Value |
|---|---|
| Git & Advanced Features | If you need advanced Git features, check out the So You Think You Know Git series. |
| b4 |
Highly recommended. This tool automates format-patch, mailing list submission, and checkpatch, significantly reducing patch submission time. (How to use b4). |
| git send-email | The core mailing list function. Setup instructions. |
| kworkflow | An end-to-end workflow tool for building, testing, and patching. (Tutorial here). |
| Krepair | Generates the minimal .config needed to test your patches, saving compilation time. (Video). |
| virtme-ng | A wrapper around QEMU for quickly testing your patches in an emulated environment. (Blog post). |
| cscope & kbuild | For code navigation and understanding the build system. (cscope video, kbuild video). |
🐛 Debugging and Testing
- Bug Reporting: Learn to use syzbot reports for finding and reproducing bugs. git bisect for bisecting bug to a commit(sysbot does this for you)
- Analysis: Static and dynamic analysis tools are vital (Static webinar, Dynamic webinar).
- Kernel Tests: Get familiar with running kernel tests (video 1, video 2, video 3).
➕ Additional Useful Information
- Systemtap
- Kernel Build Tricks
- Tracing: tracepoints, and events.
🛣️ Chapter 3: The Mentorship Journey and Lessons
I was accepted on Sept 6th after completing 12 informative prerequisites. They were an excellent crash course in kernel development workflow.
NOTE: If you are applying to full-time, be realistic about the time commitment. You need 30-40 hours a week. Juggling a hectic day job and mentorship is challenging.
My initial, optimistic plan was to complete all work before the holiday season (Nov-Dec), when maintainer review speeds drop off. Reality quickly set in; I was occupied until mid-October and focused primarily on tools and bug reproduction initially.
TIP: Get your patches reviewed early. The process is lengthy, and reviewers are busy. Early submission means early feedback and a better chance of merging on time. Also, constantly check mailing lists for the latest (K)TODOs, as older ones might not be valid now.
The First Patch: Overcoming Intimidation
I initially set a goal to work on a minor bug just to test the waters and get familiar with the mailing list review process. I picked a documentation bug (a broken link), and it successfully went through with minimal comments on formatting. The initial stress of patch formatting and sending was high, but it quickly became routine.
The Core Task: Checkpatch and Consensus
After realizing I was often beaten to simpler bugs, I prioritized a checkpatch TODO. The goal was to introduce a check for uninitialized variables using the __free attribute, which prevents undefined behavior when memory is freed upon scope exit.
The task required me to learn Perl quickly, which was a struggle. When I finally sent the patch, it involved extensive discussion and multiple reviewers. I even witnessed disagreements between maintainers on the correct technical implementation. This wasn't a roadblock, but a vital lesson: kernel development is a deeply collaborative, consensus-driven engineering effort. I had to go through several versions, and even temporary reverts, for what seemed like a straightforward fix.
By the first week of December, the main patch, along with supplementary patches fixing existing instances, was successfully merged into linux-next.
NOTE: Using AI for code generation is strictly prohibited and can lead to dismissal from the Mentorship. Always ask your mentors before doing so.
Despite having an open-source background, this experience was uniquely challenging and motivating. It solidified my confidence in contributing to massive codebases.
🎯 Chapter 4: Looking Ahead
I am currently working on filesystems TODOs and delving into The Linux Programming Interface—because once you start going deep, it's hard to stop.
My eventual ambition is to become a maintainer for one or two subsystems (preferably fs) in the Linux Kernel.
Top comments (0)