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?"
...www.kernelnewbies.org is supposed to have a lot for the aspiring kernel hacker.
I think the kernel docs would be a good starting point.
/usr/src
2 .4.17.tar.bz2
cd
wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-
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?
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.
Index of Documentation for People Interested in Writing and/or Understanding the Linux Kernel >>c kers-docs.html
http://jungla.dit.upm.es/~jmseyas/linux/kernel/ha
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
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
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.
Have a look at the Kernel Janitors Project and perhaps KernelNewbies.org .
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
.. 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
If you like to see how things work, the best way is usually to write some code that tries it out. With a little extra work, you can create a small test case. Then submit the test program to the Linux Test Project.
Linux desperately needs more serious testers.
LTP - http://ltp.sf.net/
I was glad to see Alan Cox say so, and here's a little personal experience:
:-) You need only drop into root to lilo/reboot
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
Cheers.
Let me say that, at least for me, this was not like debugging any of the userspace programs that I had done before. If you're like me, when your program crashes, you first up gdb, load the core, and backtrace/step from there. First of all, there's no core dump. In this case I didn't even have the luxury of an oops readout; as I would find out later this particular bug was locking the computer even before the kernel could flush its output buffers and print to the screen.
So I had to start meticulously reconstructing the function call stack using printk(). It took me awhile before I figured out why none of these were getting printed (for the reason I just mentioned.) So that didn't work either.
I searched high and low but never did find a way to debug the kernel that was as easy as using gdb to debug a userspace program, and that's not saying much. No stepping, no backtraces, nada. The "bug" in my particular driver consisted of a single offending line which wrote an 8-bit register and was not to spec. I would have never ferreted it out if I hadn't "stumbled" across the NDA'd specs myself.
Anyways, moral of the story: kernel debugging sucks for really hard bugs. If anyone knows of better tools to use kindly inform me of them.
I think there is a world market for maybe five personal web logs.
You can find a half baked kernelhacking-HOWTO at http://www.kernelhacking.org