Slashdot Mirror

← Back to Stories (view on slashdot.org)

Breaking Into The World Of Kernel Hacking?

Posted by Cliff on from the learning-the-innards-of-a-penguin dept.

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?"

4 of 202 comments (clear)

  1. In honor of all the linux newsgroups... by FortKnox · · Score: 4, Insightful

    ...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!
  2. Take it straight from the man... Just Do It by FauxPasIII · · Score: 5, Insightful

    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
    1. Re:Take it straight from the man... Just Do It by Jeremy+Erwin · · Score: 5, Insightful

      Hacking the kernel can seem like a daunting task, but nothing focuses the imagination like broken hardware.

      Two cases in point: (the first one isn't a linux story). Someone gave me a joystick for a macintosh. I already possessed a flight simulator for the machine, but much to my chagrin, the joystick didn't have the right drivers. So, I spent the next few weeks writing a device driver (modifying Apple produced code, mostly.)

      Second: I owned a DVD drive with broken firmware-- the capacity wasn't reported correctly, and so oms would stop in the middle of the movie. With the (very) extensive help of "Andrew Ebling" (of kernelhacking.org, I was able to solve my problems.

      Moral of the story: it helps to have good developer documentation, and example code (provided, for the most part, by the kernel source itself) It also helps to have a reason to code.

  3. Do as I did by ajv · · Score: 4, Insightful

    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