Paths to being a kernel hacker(jvns.ca)
jvns.ca
Paths to being a kernel hacker
http://jvns.ca/blog/2014/01/04/4-paths-to-being-a-kernel-hacker/
7 comments
If you're a man and are gender queer or gender fluid you could always apply here: http://kernelnewbies.org/OPWApply
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 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...)
I'm genuinely curious about what they mean by 'gender queer': OPW stands for Outreach Program for Woman, which makes me suspect they're including that phrase to try to prevent drawing any lines re 'what is a woman', so I'm a tad curious about their stance on accepting a non-effeminate gay male in the OPW program.
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.
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.
Interesting how the first link doesn't define "gender queer" or "gender fluid". How do you verify the feelings of a person about their gender? I reject gender as a system entirely, does that make me "gender fluid"? Doesn't OPW stand for "Outreach Program for Women?"
And you must be a college student.
I seem to recall that getting started in BSD kernels looked easier, at least 10-12 years ago. More organized, plenty of literature, and (Theo notwithstanding) a friendly community.
Personally the first kernel I fiddled with was Haiku's, followed by BSD. The latter especially was far easier to understand (especially the old versions) than linux is today, IMO. Not that that's a bad thing per se, as linux is incredibly functional, but when I was getting into os development, having something to read through that I could grok easily was more important. I'm currently hacking on RetroBSD, which as it's based on BSD 2.1, is quite nice! Runs on my new Fubarino board too, at least in theory. I haven't quite got it booting yet ;)
And better tooling. I'm unspeakably biased here, but I can't imagine doing kernel development without DTrace. (Actually, that's not true, because I did kernel development for many years without DTrace; it sucked.) So I would start with the BSDs or one of the illumos variants (e.g., OmniOS or SmartOS), and ask about small yet interesting open problems -- of which there are plenty...
I agree... even more recently, about a year ago I ran into a minor glitch in the OpenBSD kernel while porting an application. The kernel was so simply and sensibly laid out that I was able to quickly identify and submit a patch for the problem, even though I'd never looked at the OpenBSD kernel prior to that. (Meanwhile I'm still trying to wrap my head around Linux...)
I'm honestly surprised how simple this code is, now that I started reading it. Julia, you've shown me in one succinct article that the linux kernel isn't a big scary black box of a place, and that maybe I too can hack on it or write modules.
The kernel code also reminds me a lot of the code to Node.js circa 2009/10, which I find a little strange.
The kernel code also reminds me a lot of the code to Node.js circa 2009/10, which I find a little strange.
Interesting.
I think the mnt_* call is checking if the file system is mounted/accessible to write the change to the objects inode entry.
I think the mnt_* call is checking if the file system is mounted/accessible to write the change to the objects inode entry.
Yeah, it is, I just read up on it, it's this function: http://lxr.linux.no/linux+v3.12.6/fs/namespace.c#L404
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.
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.
The linux kernel source is objectively bad. It's fast and efficient, but I wonder how many man months are wasted every year by kernel hackers trying to keep all of these arcanely-named functions and structurez and variables in their head, or how many more bugs could be caught and squashed if the barrier to entry wasn't so high. A better code climate benefits everyone, and it's surprising that I haven't heard of any projects to make the source more accessible. We have all the RAM we could ever dream of, let's put some noobworthy comments in those files...
You claim it's objectively bad then only cite subjective things like function, structure, and variable names.
That word doesn't mean what you think it means :-)
That word doesn't mean what you think it means :-)
Minix 3 seems like a really good route for this purpose. Supposedly a kernel in less than 10k lines of C.
"Writing your own OS." Eh? Seriously? Maybe if processes were somehow linked to Dogecoin and DOOM.
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.
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.
Agreed. Having an actual project in mind, and not just throwaway code, is extra motivation.
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.]