Ever dreamed of contributing to the Linux kernel? Being a part of Google Summer of Code (GSoC) made that dream a reality for me! This prestigious program allows students to work with open-source organizations on real-world projects. I’m thrilled to be sharing my GSoC journey with you in this blog series.

Hi everyone, I’m Animesh Agarwal, a pre-final year CSE (specialization in Cyber Physical Systems) student at Vellore Institute of Technology, Chennai. This summer, I’ll be contributing to the Linux kernel!

Why I chose The Linux Foundation?

I’ve always been passionate about open-source software and the impact it can have on the world. The Linux Foundation is at the heart of this movement, supporting some of the most innovative and essential projects out there. Contributing to such a vibrant community during GSoC seemed like the perfect opportunity to not only sharpen my technical skills but also to collaborate with like-minded individuals who are as enthusiastic about open-source as I am. Plus, it’s a great chance to give back to the community.

Application period

The Linux Foundation had a list of projects for GSoC’24 out of which I chose the Device Tree bindings project as it was an opportunity to contribute to the Linux kernel which I did not want to miss. I spent the month of March familiarizing myself with the device tree, device tree bindings, and their conversion to device tree schema. This is an ongoing project in the Linux device tree and everything is well documented. After reading all the documentation I sent my first patch.

Immediately after my first patch got accepted I started drafting my proposal , for a successful GSoC application, drafting a well-structured proposal goes hand-in-hand with ongoing interaction and collaboration with your mentors, I’ll be sharing my GSoC proposal in one of the blogs in this series.

Patches

My first patch was converting the Freescale imx-pata binding to DT schema. It encountered several challenges during the review process, resulting in multiple iterations to address issues and refine the implementation. Despite the initial setbacks, I persevered and diligently incorporated feedback, leading to significant improvements in subsequent versions. While the process took several iterations to reach an acceptable state, this experience provided valuable insights into the rigorous standards and best practices upheld by the upstream community.

With the lessons learned from my first patch, I approached the development of my second patch with greater confidence and proficiency. This patch underwent smoother review proceedings, encountering fewer errors and requiring minimal revisions before acceptance. The successful submission of my second patch validated my growth and competence as a contributor within the upstream community.

I then sent 3 more patches and all of them went smoothly and were accepted for-next (6.10 kernel) in the respective maintainers’ fork of linux.git.

I’m incredibly excited about continuing my GSoC journey and sharing my experiences with you all in this blog series! Stay tuned for the next installment.