So, my OPW internship with the Linux kernel ends today. It has been an amazing journey throughout with the support of the awesome community and mentors. I would like to share a brief summary of my work, what I learnt and leave future novice contributors with a few suggestions.
My journey with the Linux Kernel began about 10 months ago. At college, I had been using Linux from the start and then we had a operating systems course. So, while learning the course and working on the assignments which involved the complete implementation of grub and the command-line, it came to my mind one day, why not look into the code of one of the greatest operating systems, Linux, that had been my primary OS for a long time now. Getting the linux repository turned out to be much simpler than I had thought. So, I began reading through the code, trying to understand and connect the dots, obviously I needed guidance. So, I did some research and got introduced to the awesome opensource Linux community through IRC and the mailing-lists and henceforth began the amazing journey of development with Linux kernel.
Reading through the code, I saw some inconsistencies in coding style and could conclude one of them must be the right way, but which. Then, the documentations came to the rescue. Linux has a short concise documents for everything like for the Coding Styles which is followed religiously across the kernel. There is a tool called checkpatch that serves just to enforce proper coding style in patches being created. So, I started off with small code cleanups, which were welcomed by the community and served a great encouragement.
I got interested in the endian-ness errors that have unfortunately found there way into the kernel and a tool called sparse has been developed to detect such errors. I ran the tool, analyzed the results(be careful there may be false positives) and sent-in patches to ensure the code does not crash on architectures with different endianness.
But as I got involved more, I found some errors that were common across many places and were quite specific. I happened to see some patches in the kernel that used Coccinelle(something that was entirely alien some months back :P) and realized that the coccinelle scripts could be run on any other file also and it would solve the same bug if it existed there. I came up with some simple Coccinelle scripts to detect and transform common bugs in the kernel. Then during the application period Julia had put up some challenge problems, that caught my attention and were very interesting to solve. The project Coccinelle went on to become my OPW internship project and my journey has been traced in the blog below.
Some major tasks done were:
1) Wrote Coccinelle scripts that are now in the scripts directory of kernel, helping developers to look for bugs to solve or detect bugs in the code being added.
2) I wrote a couple of managed interfaces for memory allocation so that the developers need not worry about explicit freeing of memory to prevent memory leaks.
3) Sent-in numerous patches solving bugs detected by the Coccinelle scripts and some others that I found along the way.
1) I have a good understanding of how drivers are managed by the kernel, what happens when they are connected or disconnected, how failures are handled and so on.
2) I have developed insights to detect cases that can be solved by Coccinelle, as I am now aware of the various facilities provided by the scripting language, its capabilities and limitations.
3) I have gained a broad level understanding of how such a huge project runs smoothly with thousands of community members across the globe, helping each other contribute and help maintain the kernel.
Few suggestions that were important points I learnt from the community:
1) Before making a general change, maybe by looking at the previous patches etc., understand the code. There might be some peculiarity hidden in the similar looking code. When I say understand the code, I mean be sure of the impact of the change, why it is being made and what other ripple effects it can cause :).
2) Rather than guessing things that you only have a small clue of, go ahead and ask the developers, most of them are very active and would be happy to answer your questions.
3) While writing be specific, concise and clear. The community is huge with each member having other commitments as well, so it is good if he has to spend less time understanding your query.
I have through this journey learnt that apart from great coding, Opensource is about collaborative learning and innovating ..Its about the thrill of solving your first bug, making friends, improving your skills, experiencing lows.. but cutting through them and rediscovering your highs. Its about joining a community (and a family) and never wanting to leave!
I would like to express my gratitude to everyone in the Linux community. Special thanks to Julia for being the most awesome mentor ever, always encouraging me, helping me improve, allowing me to experiment and learn a lot :).
I won’t say a goodbye as I am not leaving :p (Yes! I plan to stick around for a long, long time !)