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

10 of 202 comments (clear)

  1. kernel docs? by Squeezer · · Score: 5, Informative

    I think the kernel docs would be a good starting point.

    cd /usr/src
    wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2 .4.17.tar.bz2
    tar -jxvf linux-2.4.17.tar.bz2
    cd linux/Documentation
    ls |more

    and start reading all the documentation in there. It would probably make a good starting point.

    Plus you should read Kernel Traffic and get on the Linux Kernel Mailling List.

    --
    Does the name Pavlov ring a bell?
  2. Linux Device Drivers by AutumnLeaf · · Score: 5, Informative


    One of the best sources of information is the O'Reilly book on Linux Device Drivers. It contains a lot of good information to get a kernel hacker up and running.

    1. Re:Linux Device Drivers by YetAnotherLogin · · Score: 5, Informative

      And you didn't link to it? Shame on you!

  3. Index of Documentation for People Interested... by ekrout · · Score: 5, Informative

    Index of Documentation for People Interested in Writing and/or Understanding the Linux Kernel >>
    http://jungla.dit.upm.es/~jmseyas/linux/kernel/hac kers-docs.html

    The info was compiled by Juan-Mariano de Goyeneche after folks on the kernel list asked the same questions time & time again.

    --

    If you celebrate Xmas, befriend me (538
  4. Alan Cox's Columns by pthisis · · Score: 5, Informative

    Linux Magazine's Gearheads Only is a great column to read for this, especially the mouse driver and Alan Cox's articles.

    Their web site should have archives.

    Sumner

    --
    rage, rage against the dying of the light
  5. VMware? by larien · · Score: 5, Informative
    It's probably a good idea to run your 'hacked' linux under a virtual system such as VMware or user mode linux; that way you can do quick reboots without losing your MP3 player, email client, web browser, IDE (VIM+gcc, right?).

    It also means that when you screw things up (if you don't, I'd be surprised; I bet even Alan Cox screws up now and again), you won't lose anything. And don't give me anything about ext3; if you screw up enough in the wrong place, your filesystem is hosed.

  6. Kernel Janitors by auto112456 · · Score: 5, Informative

    Have a look at the Kernel Janitors Project and perhaps KernelNewbies.org .

  7. Buy crappy hardware.... by (H)elix1 · · Score: 5, Informative

    Nothing taught me more about kernel modding than spending a few dollars less on the hardware I used on a linux box - and then try to get it to work.

    You become very familiar with code that might be close, get to pour over specs that may or may not help, and find a small comunity of others who saved a buck or two.

    The best part - when it breaks, you get to keep both peices. When if finally works, ahhhh....

    --
    +++ UGUCAUCGUAUUUCU
  8. Linux Internals, by Moshe Bar.. by studboy · · Score: 5, Informative

    .. is recommended. It's a medium-low level view of the entire kernel, following the source code but making it more readable. If you've taken an Operating Systems or Unix class you should be fine.

    Linux Journal reviewed it.

    - j

  9. Re:Take it straight from the man... Just Do It by nwanua · · Score: 5, Informative

    I was glad to see Alan Cox say so, and here's a little personal experience:

    For the past two and a half years, I've been putting some logging code into various parts of the filesystem (ext2, vfs and block device driver.

    This has involved creating new syscalls and user level code to transmit logged data to a remote machine via UDP so we won't adversly affect the FS by logging _and_ writing log data to the same FS. Really trivial stuff in retrospect: the hard part was figuring out where to put what and how to do it without crashing (I worked via ssh and if I hosed something, I was out of luck until I could physically return to campus - which could be as long as a week).

    My favourite book for this has got to be "Linux Kernel Internals": consice, precise with decent examples (IMHO).

    Funny, I worked on module device drivers for a VHDL class _after_ I worked with the kernel directly, so I won't say to you: play with device drivers first to get your feet wet (although, load/unload kernel sure beats the hell out of rebooting). Try doing something simple like changing the messages (printk) within the kernel as a way to gain a small understandinig of what's happening under the hood. And another thing... the source tree I played with was owned by me (so I could cvs, nfs, coda it to my laptop without fear while playing with code (on an OSX PB) on the road :-) You need only drop into root to lilo/reboot

    Cheers.