Building Linux Device Drivers – Part 2: Surviving and Thriving

Feels like eternity since I penned something down. I’ve been a bit busy finishing this up. Feels good to say that I have actually contributed to emulating a physical hardware device as a virtual video test driver in the Linux Kernel!! This actually feels surreal.

So for today, I will break down the experience into three parts:

• The Good: Conquering the Learning Curve (or at least trying to!)
• The Better: Wrestling with Problems Like a Pro
• The Best: Cheers to the People Who Made It Worthwhile!

The Good: The Learning Curve

Let me take you back to October 2023 when I first installed Ubuntu Linux on my Virtual Machine. Back then, I was as green as could be, with only a vague recollection of the C programming course I took three years ago at school. To say the least, I was ill-prepared for the job that lay before me.

Those initial days were far from easy. Figuring out how to build and compile the kernel while dusting off my C skills felt like navigating through a maze blindfolded. And if that wasn’t challenging enough, imposter syndrome paid me a visit at the worst possible moment, leaving me second-guessing every patch*¹. Even though I am naturally inquisitive, I was scared of asking questions to my mentor because I thought that maybe I should know these things.

But I wasn’t about to let self-doubt hold me back. I resolved to embrace the learning process. I went back to basics with C programming and soaked up all the info I could find about the Linux Kernel. The kernel also has a wonderful page that helps people get started on building on the kernel.

However, my biggest resource were my mentors(more on them later) who literally held my hand through out my entire learning process. From when I asked them how to read the kernel log with the ‘dmesg’ command up until when I was discovering deadlocks in my code —which was by far the most exciting thing I did in the kernel. Slowly by slowly, I became more confident in the code I was writing and became much quicker in submitting patches. Six months down the line, I am still so fascinated by the intricacies of Operating Systems, especially the Linux Kernel and look forward to exploring a career in this.

The Better: The Problems

Right from the start, I’ve seen problems as the price I pay for learning in the School of Hard Knocks. Every mistake, every hurdle—it’s all part of my journey to get better at what I do.

1. Returning back to C development, memory leaks welcomed me like old acquaintances in a fashion show—always making a surprise appearance. I’d confidently submit a patch, only to receive an email pointing out glaring memory leaks. How did sneaky memory leaks slip past my radar? The answer was clear: I hadn’t tested my code enough.
   • Lesson learned: Test! Test! Test! And just when you think you’re done, test a bit more. After a few more patches, I finally mastered the craft, dodging most segmentation faults. And when they did pop up, I became a pro at debugging my code to spot them. Crisis averted!
2. Dealing with segmentation faults was at least straightforward—the output made it clear what went wrong. But when it came to deadlocks, it was a whole new ball game. They lurked like invisible elephants in the room, bringing everything to a standstill without warning. My mentor suggested that I should look at a few chapters on Concurrency here. And that was indeed a lifesaver.
   • Lesson learned: Multithreading is a whole new world, with tools like semaphores, mutexes, spin locks, and work queues each serving their own purpose. Hats off to computer scientists for their genius! As for detecting deadlocks, well, let’s just say it’s still a work in progress. Learning more about protecting and accessing resources at different levels in the operating system. Here, I can say, crisis managed :-).

The Best: The People

This journey wouldn’t have been possible without the incredible support of those who guided me every step of the way. First and foremost, I want to extend my deepest gratitude to my mentors, Hans Verkuil and Johan Fjeldtvedt, whose patience knew no bounds. When I embarked on this project, I was a complete novice, but thanks to their unwavering support, I can now confidently share my experiences and insights from working within the kernel. It’s surprising how it sparks engaging conversations and piques people’s interest more than I ever imagined. I’m immensely thankful for your dedication to my learning, for always being there to answer my questions, and for providing invaluable opportunities for me to grow as a Linux Kernel Developer. Thank you from the bottom of my heart.

I also want to express my gratitude to all the members of the Linux community who generously reviewed my patches. A special shoutout goes to the Outreachy community coordinator, Julia Lawall, whose support throughout my internship was invaluable. Additionally, I’m deeply thankful to Outreachy for providing this incredible opportunity. Your dedication to amplifying the voices of underrepresented individuals through Open Source is truly commendable. I never imagined myself delving into the Linux kernel, but thanks to Outreachy, it became a reality.

Last but certainly not least, I want to extend my thanks to God, my family, and my friends for their unwavering support throughout this journey. Your encouragement and belief in me fueled my determination every step of the way. And remember, this is just the beginning!

1. Sending a patch to the Linux kernel means proposing a set of changes or improvements to the source code of the Linux operating system. For those in Software, it’s more or less what a pull request is on Github. ↩︎