Translation: If you are a man and you're reading Path 3, stop now and go to Path 4.
The rest of them seem pretty decent though, so I'll get working on rustboot and such.
[edit: Downvoters, can you explain how someone without any prior kernel experience is supposed to apply and get into the Google Summer of Code program to focus on kernel development? That is an invalid path. See this answer, for example http://www.reddit.com/r/cscareerquestions/comments/193zdh/ho.... The only realistic way to get into GSoC is if you have a very clear idea about what sort of contribution you are going to make. Preferably, you should have made some already.]
If you happen to be a person of color or disabled you could always apply here: http://www.findinternships.com/2013/04/Explore-Microsoft-Int...
Or if you happen to be a straight white man you can apply for one of hundreds of linux kernel internships already dominated by straight white men (e.g. http://jobs.akamai.com/job/Cambridge-Linux-Kernel-System-Sof...)
If not, according to the article I'm out of luck because I don't qualify for GSoC either. Sad face. Genuinely interested in alternatives to GSoC and/or other avenues for jumping in to the Linux Kernel.
The kernel code also reminds me a lot of the code to Node.js circa 2009/10, which I find a little strange.
I think the mnt_* call is checking if the file system is mounted/accessible to write the change to the objects inode entry.
From what I can gather, if the file handle isn't in write mode or is a special file, then we call __mnt_want_write, http://lxr.linux.no/linux+v3.12.6/fs/namespace.c#L305, otherwise we clone the write handle or something.
I'm surprised how simple this code seems.
That word doesn't mean what you think it means :-)
I'd say if there's something that doesn't have a driver, and you need it, that's motivation enough. I remember one of my coworkers busting out a driver for the cuecat and some random sony vaio peripherals.