Outreachy application process

Number of patches submitted: 5

Choosing the project

I first started by picking the project and mentors.

I had a specific goal coming to work on the kernel. I have previously worked on many boot loaders at my previous job and was now looking for more of a challenge. I had previously chosen boot loader because I did not want to get lost in the software, but actually wanted to learn how one small OS could keep the hardware working. The kernel was a good option because of the challenges involved with multiple architectures, bigger operating system, and working with the community itself.

I read about mentors and I thought Arnd was a good fit for me. The project was also a good fit as the scope of it was in line with my goals. I did not want to work on one portion of the system, or on drivers. I wanted to touch as many subsystems as possible.

Picking the patches

As the application process suggests, I wanted to be considered for the internship. I wanted to submit a patch that would be accepted and not controversial so my application could be considered. I wanted to get it out of the way. This was also because I feared that if I picked a complicated patch to begin with, I might not be able to complete it in time. This also let me test my email set up, right tree configuration etc.

The 2 patches fixed a couple of checkpatch errors. I did not get many suggestions on these, except that Julia had a style preference for macros.

Connect with the mentor

I have always been quite thorough with my work. So I would figure out how to test after design. I wrote to Arnd about it and he suggested that the community makes small patches, so a compile test and rigorous review will suffice most of the times.

Next I wrote to Arnd for some subtasks. I believed I needed a dedicated effort so that I could start diving deeper into the kernel. Arnd suggested that I start with easy and work my way up to tricky problems on his task list.

Introductory problem

I first started with learning about different timers. I read the timer docs from the Documentation directory and then the paper by John Stultz. It was easy to for me to understand timers and the actual hardware blocks used because of my experience. I had written a driver to use timers to support context switching in my boot loader which used round robin scheduling. This was also my favorite driver as it showed how the basic blocks work: scheduling, timers, interrupts, context switching etc.

Next I fixed a staging driver. But, while Arnd and I were arguing over why I had chosen to do the patch this way, Arnd discovered that the whole driver might not be required any longer. Greg suggested I delete it and so much for my first patch! But Arnd was gracious enough to let me do the patch to do the removal.

Medium problem

Next I chose a medium problem: usbtest ioctl

This was quite fun as I got to learn that this was implemented as a USB driver. The higher level framework was doing the conversions for compat mode. I again read a bit about ioctls, looked at header files, figured out what uapi files are, also did some research on CONFIG_COMPAT ioctl.

I got a little pedantic and introduced a new ioctl. I said the ioctl interface was never implemented correctly. Arnd gently steered me towards just fixing the data types. I ended up adding ioctls for 2 different input structures of different sizes.

Tricky problem

Next I chose MD problem, which was called a tricky problem.

This needed a little understanding of the MD driver and RAID.

I interacted with Neil, and Arnd had already started a discussion on the right approach.

Conclusion

These were the only patches I submitted through the application period, and my last one was merged after the application period was closed.

I was looking for someone who could see that these patches were different and could see my potential. I did not want to do more clean up patches. This approach worked for me.