Slashdot Mirror
Becoming a Linux Kernel Programmer?
Young Grasshoopa asks: "In my 6 years of IT life, I've been a sys admin, perl programmer, and a config. mgmt. engineer. I've recently learned programming in C, and somehow ended up learning a bit of Linux Kernel programming as well. I now have developed a strong motivation to become a Linux kernel developer, but given my background, I am not sure how to approach companies or Open Source Project groups. I ask all those who were in a similar situation - how do you become a full-time kernel developer?"
Start for free. Sure, it sounds odd, but you have to get your foot in two doors. First, the linux kernel proper. Second, a company or position that will pay you for the privilege.
If your code isn't accepted into Linus' kernel, why should they pay you? I'm sure there's a lkml faq that has answers for the first step. Finding an employer who will pay you... I understand Red Hat will have an opening, now that AC is taking a sabbatical:)
Jesus was all right but his disciples were thick and ordinary. -John Lennon
KernelNewbies?
If you have, you may want to consider starting out as a kernel janitor (basically doing assloads of grunt work to build a name for yourself).
I would consider myself a kernel developer at this stage, even before my driver is included in the mainstream kernel versions.
It sounds like you are at this stage already, so are you actually asking "How do I get a driver included in the kernel as distributed?". Well I think the answer to that is to keep submitting it to the maintainer of the relevant kernel. Things like revelance, and especially quality are important factors too.
For anyone at an earlier stage, perhaps "normal" programmers who need to learn how it all works in the kernel, I have (reccomend is too strong a word, as I have only read these 2 books on the topic) read 2 OReilly books.
Understanding the Linux Kernel, 2nd Edition and Linux Device Drivers, 2nd Edition
Of course you should also be on the linux kernel mailing list
And the rest is dependant on exactly you want to add to the kernel.
the easiest way would be
to start as a part time kernel developer.
find something wrong.
fix it.
find who's in charge of that code.
send it to them.
if there's not anyone,
contact one of the high mucky-mucks,
and let em know.
maybe the maintainer will be you.
An OS programmer compared to a low-level IT worker? You must be joking.
May we never see th
Your best bet (not that I have done this or have any inclination to do so) may be to be a part of documenting the code area(s) you are interested in working on. This will thoroughly acquaint you with the code and provide a much-needed service that may get your foot in the door.
.sig generator v.1.0.
Just a thought,
bmac
Peace be with you all.
Manual
The Linux Kernel Janitor Project might be a good place to start.
http://sourceforge.net/projects/kernel-janitor
Nevertheless - the parent post does have a point. Kernel developing isn't going to be very lucrative. One of my friends had his contributed code accepted into the Linux kernel - for a little bit of fame, glory and geek points. I think the only mainstream OS developers that get any money these days are at Microsoft and Apple (or behind closed doors at IBM, Sun, etc).
OS design and IT work still solve technical problems - but the deeper ones such as OS design are a lot less visible to the pointy-haired-bosses than the "my printer doesn't work" ones. Therefore they're a lot harder to get $$$ for in general.
Having written an OS (as a toy back in '96), it's not that amazingly glamorous, there's a lot of painstakingly detailed work.
Assuming you want to get paid, I think there are two "easy" ways of getting to do kernel programming.
...) Companies making computer hardware need drivers for them and somebody has to code them.
The first one being embedded systems. A few friends have already done that. There are lots of companies making their own hardware devices: firewalls, toasters, gadgets, etc. Linux is a popular OS for that market and you're likely to touch different parts of the kernel.
The other market is device drivers hardware (Printers, webcams, network cards, joysticks, etc
Good luck !
---
If you're not living on the edge, you're taking up space in the middle
Find something that you think the kernel needs or that the kernel needs to do better and work on it. Look at areas of the kernel that you specifically use (i.e. networking, NFS, Netfilter, etc.). Work on something that matters to you and nothing bad can come from it. that.
Now, I've never met or know any kernel hackers, so the points above are just wild guesses...
Linux "kernel development" is a pretty broad term. It can mean anything from mucking with the lowest of the low level junk to writing simple device drivers from existing templates, which mostly amounts to filling in some blanks.
Getting paid to develop low level kernel functions is probably the hardest thing to do. Partly because it's just very challanging programing. In fact a lot of it is less programing and more mathematics. If you haven't taken a class in Discrete Mathematics and done well, it's probably not for you. You may still be able to handle low level hardware interface issues, but forget about coming up with any brilliant new VM algorithms. It's also hard to get a job doing that because companies know that very few people on Earth can do it consistently well. Also, most companies don't see a direct benefit from it and therefor don't care since they can't see past their nose. They don't care that Linux will have 0(1) scheduling in two years if it doesn't increase sales tomorrow. This type of kernel development is typically bleeding edge and reserved for super-geniouses with a vision.
The easier way to get into kernel programming is probably driver development. There are a lot of companies that design computer hardware, and (hopefully) they'd all like to have Linux drivers for their products. Drivers are relatively easy to develop (once you know how), they all have a lot in common and there's a pretty good body of driver source code you can work from, and a large body of theory available in text books and whatnot. Writing everyday drivers typically isn't bleeding edge work and can be performed by your average sub-genious.
Either way, getting a job in the computer industry is hard right now. It never hurts to apply for jobs, but your odds of actually getting one will be a whole hell of a lot better if you have some kind of programming portfolio you can use to show off your stuff. Companies will be a lot more likely to hire a tried and true kernel programmer than a wet-behind-the-ears newb. So I recomend you get friendly with some of the kernel maintaners, reverse engineer some hardware, or pick a piece of the kernel and just do some work on it. Produce something good and then you can show it off when you get interviewed. You can't buy that kind of credential.
-73, de n1ywb
www.n1ywb.com
You get into the projects in exactly the same way: start off doing some small useful things (docs, janitor work, UI design, whatever) and then sooner or later you'll inevitably find yourself maintaining a driver or whatever. Next thing you're making changes to sub system APIs, and you work from there.
There's no magic and there is no cabal.
If you're asking about specific organisations to help you on the way in, the other posters have already mentioned kernel janitors and kernel newbies, both of which are good.
I became a kernel hacker through a rather unusual route: my M.Sc. supervisor spotted missing functionality and suggested I had a crack at it.
-- Remove the trailing '\0' to email me.
I think wanting to contribute "just because" is motivation enough ...
;).
At my POE, we are planning to rewrite a lot of stuff real soon now; when we do so, we intend to create a LOT of generic, reusable components a) for our own benefit, naturally and b) so we can contribute (the now not-so-proprietary) code back to the community, because essentially, without Free Software, we would not be able to operate (and trying to convince the boss to give money is futile
My point is, simply wanting to contribute back to the community that many of us have benefitted so much from is motivation enough; why would you suggest that someone only contribute when they have a personal need for a feature set? Isn't that sort of selfish? And so what if someone just wants to contribute for "geek points" or ego, or whatever; their code shouldn't make it into the kernel unless it is up to snuff, so to speak, so who the hell cares what their motivation is?
Find a network card that is ill-supported in Linux and start working on it. See if you can find the card in used computer places and start tweaking the code.
A while ago when I was trying out a new kernel version I saw that one of the cards I had did not compile well. I dug into the code and saw a function name change was all that was required. I had to tweak another kernel a little to get it to compile under a new gcc version. No it didnt run well but it did compile and boot.
Just exploring like this and reading the kernel hackers guide driver guide and other things will give you a good handle on the internals, at least from the drivers perspective. Several month of kernel tweaking later, the vm, scheduler and the other stuff will become clear as you gain interest. However the market will be biggest for kernel ports to new architectures and drivers for newer network adapters. Keep your skills sharp there, build a portfolio and surf dice.com regularly.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Make a compilable module for the kernel. It doesn't actually have to be in the kernel-proper code to be useful as lots of companies release 3rd-party kernel-module-source (my fasttrak promise TX2000 pro RAID card, and also the DIGI multiport card for example).
If it's useful and stable enough to be of benefit to the linux users at large, perhaps you could then lobby to have it put in the base kernel. One trick would simply be to find out a new technology or popular device that is coming out and create a decent driver module for it...
The official GNU/Hurd page.
The help-hurd mailing list archive.