Getting started with Open Source: the Linux Kernel Mentorship Program

During the past three months, I was part of the Summer '22 Linux Kernel Mentorship Program.

LKMP is one of the best opportunities for newbies to venture into Linux development. And this is because of the mentors who took time out of their very busy schedules to guide mentees. I am thankful to Shuah Khan and Pavel Skripkin for all the help they provided me over the summer.

Another reason why LKMP is an ideal way to make first contact with Linux is how the program is structured. Jumping into Linux is hard. The community functions in a certain way and the learning curve is sharp. The resources are all out there, but knowing where to look and how to start is key. LKMP has an initial period where mentees are taught exactly that.

Also, not everyone gets the chance to learn the ropes under the eye of a seasoned kernel developer and a maintainer, sound ideas off them, seek help directly when stuck and meet up every week for discussions. Most newbies rely on mailing lists and learn their way through. This takes a lot of time and patience. So, LKMP shortens the struggle by a lot.

Having said that, the kernel community is very responsive and helpful. Feedback on patches should be taken graciously. Be ready to be wrong. Remember, us mentees are newbies. The penguin logo for kernelnewbies with a baby bottle is very accurate :) The good thing is that Linux developers are always willing to offer advice, review code and clear up doubts on the mailing lists. It might take some time, because Linux is a busy community.

My takeaways from LKMP

#1
LKMP mentees need mainly 3 things. Knowledge of OS(this will improve gradually), patience and perseverance. Everything else can be picked up along the way. Diving deep into a bug and getting stuck is common. There were many times when I couldn't figure out the issue. I would go away for a while, come back with a fresh mind and look again. I would find something new in the bug. Get stuck again and repeat. The point is you have to come back.

#2
Work on the latest mainline release. Reproduce the bug on both mainlne and linux-next trees before working on the bug. Maybe the bug does not exist anymore or has a fix already lined up.

#3
Getting a hang of Syzbot will take some time. Choosing the first bug to work on is also tricky. Some bugs are harder to solve than others and you can't always tell which will be the case. Its natural to look for a simpler bug to start with. But, the best appoach would be to pick a bug from a subsystem you are familiar with, work on it and discuss with mentors if stuck.

In the end, I came across bugs of mixed dificulty. I could point out the problem by looking at the code for some and was buried into GDB with others.

#4
I need to improve my speed in solving a bug. Taking too long on a bug usually results in someone else submitting a fix before me. The process is much faster if the subsystem is familiar to me. Although, some bugs can take a long time to figure out even when I feel I understand the subsystem internals sufficiently. Therefore, LKMP is a good time to study various subsystems. It will be a plus for any future kernel development.

#5
Getting stuck for too long. Looking at myself at the end of LKMP, I feel I could have cut down the time I took for solving some bugs I got stuck in by asking for help earlier. It is easy to get so involved in a bug that you become hell-bent on finding the problem or the solution yourself. But Linux developement is collaborative. And for good reason. I've realized I must learn how to better judge when to ask questions.

Start early

To the potential future applicants, start early because the first patch will take some time. I think these two resources are excellent for getting started:

OutreachyFirstPatch: https://kernelnewbies.org/Outreachyfirstpatch 
LFD103: https://training.linuxfoundation.org/training/a-beginners-guide-to-linux-kernel-development-lfd103/