Slashdot Mirror
Breaking Into The World Of Kernel Hacking?
crow_t_robot asks: "In
the past couple of months I have become increasingly interested in
kernel programming and have finally decided to take the leap and
'get my hands dirty.' I have searched around the web and read a few
docs and FAQs on getting started with the kernel but I was wondering
what kind of personal experiences those in the Slashdot crowd have
had that are so bold as to start goofing with the kernel code. For
those that have become competent kernel programmers, how did you
'break in' and what advice would you give beginners?"
...RTFM! ;-)
Seriously, though. Try and find FRIENDLY help. Once you have that, you should be good to go. A lot of kernel hackers are very elitest, and don't take too kindly to newbies, so find yourself a good support group and go from there.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
what are your credentials. Just feeling like doing it is not enough. What is your programming experience, education, work experience etc concerning system programming?
If you don't have that much of experience, I would start making a device driver for a relatively simple device. That way you'll learn what it's about and whether you're ready for it.
I would think that anyone really going into kernel programming would have interests/ideas developed on his own on which to work.
From Alan Cox's interview posted to slashdot a couple days ago:
"Ignore everyone who tells you kernel hacking is hard, special or different. It's a large program, and bug fixing or driver tweaking can be a best starting point. It is however not magic, nor written in a secret language that only deep initiates with beards can read.
Play with it, try things, break it horribly and enjoy yourself. I started on the networking code because it didn't work very well. Everything I knew about TCP/IP I had downloaded the same day I started hacking the net code. My first attempts were not pretty but it was *fun*."
25% Funny, 25% Insightful, 25% Informative, 25% Troll
Ok, lets be honest, half way through the question I thought of posting the above, but then I read the whole question, unlike the person above, and decided that would be the totally wrong thing to do.
/. before posting, mods, please mod the above (and this if you really want to.
Think about it dude, he has spent time reading the FAQ's and such, he wants personal stories, so that is what he should get, sadly though, I don't have that many, well not of the type he wants.
I wish people would read the Ask
Take care - RL
I'm a little offended by the notion that "nerds" represent only those who program in Linux. I'm a Mac user (now an OS X user), and I can write PHP code to interact with MySQL...and I'm proud of myself! Set against the entire gamut of the North American population, I'm on the extreme end of nerdiness. But sure, if for some sick reason I was interested in Kernel programming, I would be a "newbie", and I would expect /. to be a powerful resource for getting started. I support this topic and the goals of the poster.
You can have my one-button mouse when you pry it from my cold, dead fingers.
The publisher has a sample chapter online (though their HTML looks weird to me; I hope it looks better in your browser). Also, you can read a little more about the book, find links to online reviews, get errata listings, and so on, at its support site.
Oh, and I, er, happen to know the author. :-)
``Life results from the non-random survival of randomly varying replicators.'' -- Richard Dawkins
Get down and dirty with a kernel project. I chose Reiserfs on alpha.
This taught me a lot about lkml politics, which is probably the first skill (and some larrikins would say, the only skill you need) you must master to be a successful long term kernel hacker. First lkml hint: don't slag off anyone. Don't piss off a few people in the know until you get to know them, and then...
Then, don't talk - do. Respect is directly based upon your skills with patches, and their acceptance rate.
Patch submission. Follow the standard guidelines (found elsewhere), but know now that Linus sucks at code control. The mainline kernel development process is slow, prone to serious lossage, allows regression, and is irreparably harmed by Linus' refusal to adopt modern code control practices. So when you submit a patch, don't worry if it's not accepted. Every time the kernel is revved, re-do your patch and re-submit. It'll eventually be accepted, particularly if it helps the kernel boot. For example, it took nearly a month of my submitting a two line patch to allow the alpha to boot before it was accepted into mainline 2.4.0pre development. That's why I ditched Linux for a while - dickheads in charge. All the *BSDs have better kernel development practices, and their bleeding edge kernels are far more stable than any stable Linux kernel. However, for various reasons, I get attracted back to Linux on a regular basis, like a fly to a pus-filled boil.
Anyway, the things that need desperate attention are:
the kernel janitor project (clean out the cruft!)
the linux kernel testing project
These are far more important than any single feature you might want to add, and in particular the kernel janitor project will help you get familiarized with the kernel the quickest.
http://sourceforge.net/projects/ltp/
http://sourceforge.net/projects/kernel-janitor/
Andrew van der Stock
I started programming in the linux kernel many years ago. I think the thing that helped me the most is that at first I just stuck to one thing. I didn't try to get it all at once. Kernels are very large, and there are a few tricks to kernel programming that aren't as intuitive as applications programming. After playing around in the TCP/IP stack I just branched out a bit. After a while whenever I encountered some new routines or structure, I tried to read every bit of code involved with it.
Some years later I decided to switch to *BSD. I have found their source to be much cleaner and their debugging tools are far more useful for me. After I felt comfortable enough with BSD I started contributing code back. At first small things, and then gradually larger projects. Now I do custom FreeBSD kernel code for a living. I do everything from new file systems to device drivers and custom TCP/IP code. I enjoy it much more than user space programming.. I always joke that I did it all to get away from getopt(3) though.
There are a variety of books you can read on the topic. Don't restrict yourself to linux books, please. Learn that there is more than one way to solve a problem. I'll list some of my favorite kernel books here:
"The Design and Implementation of the 4.4BSD Operating System"
"UNIX Internals: New Frontiers"
"Solaris Internals"
"UNIX Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers"
After you get a rough idea of how the kernel works, the only way to really learn it is to read code and research papers.
Good luck.