Earlier during this year, while browsing through the web, I was looking for documentation about something related to the Linux kernel. Randomly clicking through a couple of links, I found out that the Linux Foundation offers free mentorships to help people to get familiar with multiple different software projects and ideally become contributors.

For myself, a longtime Linux user on my personal PCs and for work, it quickly jumped to my eye, the Linux kernel bug-fixing mentorship. I had long wanted to contribute to the Linux kernel. At work, I do stuff related to the Linux kernel, drivers, and such, but I never had the chance to propose contributions upstream. This looked like the perfect opportunity to learn how to contribute code to the Linux kernel, and indeed it was. If you are interested, you can look at all the mentorships available at the Linux Foundation here.

To participate in the mentorship, you do need technical knowledge about Linux, and before you are accepted into the program, you need to demonstrate you can complete a number of tasks designed to test your skills. The tasks themselves are a good learning experience and will help you set up a useful workspace that can make things easier later if you are accepted in the program. One of the tasks you have to complete is a Linux Foundation training link that will explain all the processes and steps you should follow to send a Linux kernel patch for review. If you manage to complete all the tasks on time, there will be a selection process, and hopefully you’ll be notified you can participate in the mentorship.

One of the challenges that I had when thinking about what and how to contribute to the Linux kernel is context. You can only find areas of improvement or potential enhancements if you are really familiar with a functionality of a project, and in many areas or subsystems of the Linux kernel, the development is driven by contributors from companies with very clear goals. The goal to start is to find an entry point that is simple enough to understand and doesn’t require such deep understanding of the context. The mentorship will surely help in that sense, for starters pointing you to resources that you can look at to find bugs to fix, that you can try without tons of context. Also, guide you in how to approach and interact with the Linux kernel community, and the channels available. I won’t get into details, because that would be a spoiler on my end, but it suffices to say that it did help me and others to get patches accepted in the upstream kernel.

This is the list of the patches that I got accepted during the duration of the program; they are nothing big or fancy but fix potential issues nonetheless. Also, now that I have some experience, I am definitely motivated to find more areas to contribute.

ebbab41fba1bae6ccd96c0eec17026700ac6534 ASoC: stm: stm32_i2s: Fix calc_clk_div() error handling in determine_rate()
25a36912dc4456c519858179997e5375e76d6104 mmc: loongson2: prevent integer overflow in ret variable
de1c831a7898f164c1c2703c6b2b9e4fb4bebefc slab: Decouple slab_debug and no_hash_pointers
3920a758800762917177a6b5ab39707d8e376fe6 net: macb: Check return value of dma_set_mask_and_coherent()
5a5fc308418aca275a898d638bc38c093d101855 spi: spi-mux: Fix coverity issue, unchecked return value