Submitting my first patch to the Linux kernel

Submitting my first patch to the Linux kernel

Here's how I went from Linux newbie to community contributor... Hint: study the code and start out simple.

Penguin with green background
Image by :

Subscribe now

Get the highlights in your inbox every week.

I started using Linux three years ago while attending university, and I was fascinated to discover a different desktop environment. My professor introduced me to the Ubuntu operating system, and I decided to dual-boot it along with Windows on my laptop the same day.

Within three months, I had completely abandoned Windows and shifted to Fedora after hearing about the RPM Package Manager. I also tried running Debian for stability, but in early 2017 I realized Arch Linux suits all my needs for cutting-edge packages. Now I use it along with the KDE desktop and can customize it according to my needs.

I have always been intrigued by Linux hacks and the terminal instead of using ready-made unified installers. This led me to explore the Linux kernel tree and find a way to contribute to the community.

Submitting my first patch to the Linux kernel was a breathtaking experience. I started the second week of February 2018, and it took me about an hour to clone the latest Linux kernel source tree on an 8-Mbps internet connection, and nearly all night to compile and build the 4.15 Arch Linux kernel. I followed the KernelNewbies guide and read the first three chapters of Linux Device Drivers, Third Edition. This book introduced me to the device drivers, along with the specific types, and described how to insert/remove them as a module during the runtime. The sample code in the book helped me create a hello world driver and experiment with the insmod and rmmod commands (the code samples in subsequent chapters are a bit outdated).

Many people advised me to read books on operating systems and Linux kernel development before contributing; others suggested following the KernelNewbies’ guide and using the bug-finding tools to fix errors. I followed the latter advice because I found exploring and experimenting with the code around errors is the best way to learn and understand the kernel code.

My first cleanup was removing the "out of memory" warning by running the script on the vt6656 driver directory. After adding the changelog and updating the patch, I submitted my first patch on February 10. After I added the changelog, I received an email from Greg Kroah-Hartman on February 12, stating that my patch had been added to the staging-next branch and would be ready to merge in the next major kernel release.

I recommend keeping your first patch simple; one or two lines will inspire you to contribute more. Keep in mind that quality, not quantity, is what matters. Before contributing to the TODO list of the drivers, you should acquire extensive knowledge of device drivers and the operating system. The thrill of contributing will keep you going.

About the author

Dileep Sankhla - Google Summer of Code 2018 @KDE