Day 16 – Outreachy Internship

General advice to future interns

Whether you’re a genius or a beginner, we all have to deal with being stuck at some point. Outreachy know’s that most of us interns will not be superstars at first, but you know what? That’s great news, because for all of us to succeed in our communities we need to learn that this is a part of the process. This is where self doubt creeps in and if you’re anything like me you’ll immediately start asking if you’re good enough, and that everyone in the community is a genius and you’re not. I probably spent at least 15 hours a day (including weekends), just going through the codebase and emailing my mentor back and forth. I did this not only because I wanted to make a good impression but more so that I thought I would fall behind since I wasn’t familiar with the codebase.

I can absolutely assure you this is not needed and there is no need to stress yourself out if you don’t understand a part of the code. My problem was that I was confused but I couldn’t put all the fragments of thought I had into a coherent question. Mentors are truly amazing, I can’t tell you how many times I’ve been confused and researched like crazy just to come up with a question thinking I was way off. Only to get a reply from my mentor that I was on the right track and a well structured response to my questions. My advice to future interns would be to do as much research as you can then ask your mentor questions, because you need to convert your thoughts into coherent questions.

For example, Instead of saying “I don’t understand this line in this function” make a concerted effort in understanding/walking through what the function does first because this can lead to an “A ha!” moment. It can also make you change that question into ” I see that the function takes in file and converts its contents into strings but I don’t understand why this particular line is needed”. You see? one is really vague and the other one narrows it down. Lastly Always remember, everyone including mentors have lives so be patient when you’re waiting for a response, they aren’t ignoring you. Questions, questions and more questions do not be afraid to ask, you can’t get from point A to point B by standing still you have to move.

Linux Kernel specific struggles

The first task that my mentor gave me is about 90% done, and I can assure you that it wasn’t easy. A week ago I was wondering if I was cut out for this, but my drive to have a successful project outweighed the thoughts of not being good enough. The first task was to implement a mechanism to allow the queue depth of a scsi storage target to be increased/decreased.

A little background

Queue depth is the number of pending input/output (I/O) requests for a Logical volume. Imagine if there was a line to board the subway and the line by default could only hold 5 people. Trains come every 5 minutes and once they arrive it leaves a minute after the door opens. Lets suppose the train only has 3 doors, so that’s 15 people (5 per line). If its rush hour and 20 people come to use the train, 5 people won’t be able to line up. So a solution would be to increase the line so more people can line up and wait. This more or less is what this mechanism will allow.

It might sound complex but its actually rather simple once you conceptualize it however how do you translate this to actual working code? For starters where is the queue and how can you edit it? I was stuck on this for a while because I was looking in the hyper v driver folder searching for this queue structure that did not seem to exist. So I took to the internet using things like to read past commits and used google search, until I finally emailed my mentor and they provided the location (yes, face-palm, it was that simple). The next struggle came from actually trying to understand the code and also looking at implementations from other drivers for insight. During this time I probably scrapped and recreated the function I wanted to create a dozen times until finally I had one that I thought was actually right.

I definitely wouldn’t have been able to do this without my mentor’s responses letting me if I was on the right track or not. Another major help was actually reading through some of the Linux documentation. A lot of what first seemed foreign was actually just an implementation of some mechanism in the kernel, or directly using an API from the kernel. At first, this wasn’t so straightforward but I started seeing trends in other driver files. After this I started researching and it was only after reading through some of the documentation that this became apparent. Thankfully there was documentation for me to read so that I could understand everything a bit more. Below you can find what helped me out.

Some Resources that gave me that “A ha!” moment.

  1. Searching through the driver folder on the command line for specific functions or words I used the “git grep” command
  2. Searching for specific functions in files visually I used
  3. you can read the kernel documentation for specifics about certain API’s, or
  4. Also use for an easy way to search through past patches that contain certain keywords.

That about wraps up this weeks update, hope you enjoyed the post.

Until next time…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s