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

Comments

kernel docs?

[Squeezer]

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.

Linux Device Drivers

[AutumnLeaf]

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.

Re:Linux Device Drivers

[YetAnotherLogin]

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

Index of Documentation for People Interested...

[ekrout]

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.

Take it straight from the man... Just Do It

[FauxPasIII]

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*."

Re:Take it straight from the man... Just Do It

[Jeremy Erwin]

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.

Re:Take it straight from the man... Just Do It

[nwanua]

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.

Alan Cox's Columns

[pthisis]

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

very easy... 10 steps to kernel coding:

[Cheetahfeathers]

1. Learn to code.
2. Learn to code in C.
3. Figure out what YOU want to add to the source.
4. Read the kernel source.
5. Understand what you read.
6. Make changes/additions to the source, per step #3.
7. Test out the changes/additions on your own system.
8. Make it work for you.
9. Send in your contribution.
10. Have it accepted/rejected.

VMware?

[larien]

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.

Kernel Janitors

[auto112456]

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

Device Drivers

[Eagle7]

Buy the O'Reilly book on device drivers mentioned above, and pick a driver you use. Try to understand it, and then tweak it a bit. Since they can be loaded and unloaded, device drivers are a little easier/quicker to play with. And there is a good book on them. ;)

Working on it during part of an 8 hour work day, in about 1 month I was able to hack tab support into the s390 vm console driver with nothing more than reading code, searching the net, and using that book. And that was probably a little on the slow side. (see here http://www.eagle7.org/ibmlinux.html

And like Alan Cox said in the interview posted to /. a bit ago - Have Fun!

Buy crappy hardware....

[(H)elix1]

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....

Linux Internals, by Moshe Bar..

[studboy]

.. 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

Re:In honor of all the linux newsgroups...

[Dman33]

Could someone please tell me what does RTFM stand for?!?!

RTFM!!!

Thanks for the set-up! :)

Kernel trashing :)

[jd]

I've found that the kernel source code varies in quality between Ultra Brilliant to Infra Crud. (Sadly, a lot of the networking code seems to fall in the latter category.)

Probably the best place to start is to find some definite itch you want to scratch, and so badly that you won't stop until it's done. For me, that was getting use[ful|less] features into the kernel. As many as I could cram in, without the hard disk exploding. And then fixing all the incompatibilities, as best I could. (Phew!! There are generally a lot!! That's why many of the FOLK patches I produce are unstable.)

What you do next depends on the "itch":

• Fixing broken/cruddy code: Generally, it's better to rip it out and start again. Find out what goes in, what comes out, and what is supposed to happen. Software Engineers tend to talk of "black boxes", where one piece of code doesn't need to know anything about other pieces of code. It just needs to know what gets put where. You can use this to test your code outside the kernel. Simply use the kernel headers for the structures, rig up some mock values, and see if your code does what it's supposed to. If it does, then all that's left is cutting & pasting the code into the kernel. Oh, and producing a diff file for the rest of us.
  
• Adding new drivers: There should be skeleton drivers in the kernel. Simply fill out one of those. If there aren't, find a driver that's similar to what you want and replace the stuff you don't need, as above.
  
• Adding new features: Ignore the rest of the kernel, completely, at the start. Since it's a new feature, rather than an extension of something already there, you're going to be mostly writing new code and working on new structures. The only time the kernel matters is when you want to get data in or out of something thats already there, or when you want to link into some existing capability (such as kernel modules). Then, only pay attention to the API in the headers. The implementation is likely to be replaced three times before the weekend, so spending too much time on it is stupid.
  

Re:different kinds of "nerds"

[JordoCrouse]

i bet that guy can hack a kernel but can't figure out how to change his oil or replace an alternator or something like that

That is true, but in the spirit of open source, we just borrow somebody else's car.

Find a need....

[aiken_d]

Rather than just hacking in general, you should identify a particular area where kernal development has lagged. That way, you can make incremental improvements in long-neglected code rather than trying to one-up the preeminent kernel hackers.

For instance, I've noticed that there is a sad lack of resources devoted to incorporating practical jokes into the kernel. Everything is so "write to disk, read from disk, move bytes around, manage processes" boring.

I've got some ideas you might want to consider for your first project. Implement these babies, and I'm sure you'll garner a great deal of attention.

- Fake "blue screen" crashes: When "root" is logged on locally, intermittently go to a blue screen with memory dump info for a few seconds, then switch back to console mode as if nothing happened.

- "Ha! Just Kidding!" memory manager: when an app requests a memory allocation, periodically claim that it has failed for no reason at all. That'll keep 'em laughing forever!

- Unionized thread scheduling: implement the concepts of lunch breas, smoke breaks, and overtime into thread scheduling. Union threads should refuse to work with non-union threads. Periodic strikes for better working conditions, and so on.

Do a good job with this stuff, and I'd be shocked if it wasn't included in the main tree!

Cheers
-b

Before you dive in, read this!!!!

[2Bits]

Oh so, you want to hack kernel? Well, let me tell ya, before you get in this, you need to do the following prelim works:

• Divorce if you are married, unless your other half also wants to hack kernel. Even that, make sure you two don't hack the same module.
  
• Say goodbye to your bf/gf, unless your significant other also wants to hack kernel. Even that, make sure you two don't hack the same module.
  
• Get rid of redundant furnitures. You'll have a lot more computers, so you need space.
  
• Get a good air conditioner. Oh yeah, all those computers you have, it's going to be hot.
  
• Get a good and large freezer. Read next items to see why.
  
• Stack up a lot of beer, coke, moutain dew.
  
• Get a good coffee maker, with a big pot, preferably with vacuum insulation.
  
• Stack up a lot of coffee
  
• Stack up a lot of frozen pizzas and frozen food.
  
• Get rid of your lamps. You don't need that. You'll glow anyway.
  
• Get rid of all your light color clothes. Get some black clothes. Any kernel hacker worth two cans of beer will wear black clothes.
  
• Get rid of your razors. Any kernel hacker worth two cans of beer will have beard. Linus is an exception, his skin is too thick, so it doesn't even grow.
  
• Save money on soap and detergent. Any kernel hacker worth two cans of beer is smelly.
  

Ok, now you can go back to read all these good advices that other /.ers gave.

Dual keyboards with seperate keyboard mappings!

[karlm]

I did my first real kernel programming (besides a little "hello, woeld!! This is the kernel speaking" module). Last week. My keyboard died a few months ago and I didn't have time to mess with it, so I went out and baught and IBM USB/PS2 keyboard (Rapid Acess Pro) and hooked it upto my machine as a PS/2 keyboard.

When I had time, I went and fixed the old keyboard, and rearranged the keys as a Devorak keyboard while I was at it. Unfortunately, the USB-PS/2 dongle that came with my IBM keyboard doesn't work with my Dell PS2 keyboard. However, I currently have the IBM keyboard hooked up to my USB port and my old Dell keyboard (with rearranged keys) as my PS/2 keyboard.
Luckily, keybdev.c (both the one in drivers/input and the one in drivers/usb) is astonishingly short. There's all of about 5 functions in there and most of the complexity is hidden in other modules.
The USB keyboard driver interfaces the PS/2 subsystem IIRC (don't know where I read this, maybe the hid.c documentation on linux-usb) so you can't have seperate keyboard mappings, unless you munge the keycodes inside the USBdriver. As long as you don't lock up your USB keyboard driver or have a buffer overun, you should always be able to restart.
I have LILO (GRUB, actually) setup to boot me into either a 2.2.20 kernel or a 2.4.17 kernel. That way, I can ensure that my hacked module won't be loaded by hotplug if I screw it up.

The Steps I took
Downloads I downloaded the 2.4.17 source code and used apt-get to install kernel-package (makes Debian kernel packages, so your nightly apt-get upgrades won't destroy your work).
Renaming I went into /usr/src/linux (after untarring the 2.4.17 source) and changed the line near the to from "EXTRAVERSION = " to "EXTRAVERSION = -maxmodular" this changes the name of the kernel from vmlinuz-2.4.17 to vmlinuz-2.4.17-maxmodular and makesa seperate directory in /lib/modules for your hacked modules. (I called it maxmodular because I even made the "misc binary support", "a.out binary support" and "floppy drive support" as modules.) Potential Gottcha: IDE support is no enabled by default, and comes after the IDE-parport questions in the config menu, so I must have recompiled 10 times trying to figure out why it couldn't mount the root partition.
Snooping arroundI poked around the drivers/usb/ kernel source and documentation some to try and figure out what needed to be hacked. I incorreclty identified drivers/usb/keybdev.c and after none of my printk's worked, I tried drivers/input/keybdev.c (this does not affect the PS/2 keyboard).
Printk() is your friend. Add printk()s (printk() works just like printf(). Make sure to do your kernel module insertion from a non-X virtual terminal to minimize the time it takes prints to get to you in the case of an impending crash.) to the beginning of every function in the driver, letting you know that it's being called (and optionally the arguments). Then recompile and load your module. This gives you a feel for how the driver works and confirms that you have the right driver.
Trim prink()s to only print out the information you need. In my case, I got rid of the printks from everything but the keyboard event handling function and the emulate_raw function kalled by the event handler. I printed out every keycode that was pressed (but not it's release) so that I could write down the keycode for each key I needed to remap. (And some of the neat colorful buttons IBM added above the funtion keys. I later used these to turn on and off the devorak remapping and turn on and off the printks in my module.

After that, what you do is pretty specific to your module. For keyboards, they send a 16-number, called a scancode that is one of the arguments to the keyboard event hadler function. All of the normal keys have scancodes less than 256, so I just made an unsigned char[256] usb_key_remap_table and did something like
if (code < 256 && code >= 0) {code = usb_key_remap_table[code];}
The more astute amoung you will remeber that I'm only remapping the USB keyboard, which is my good keyboard and therefore unmodified. Oh well, I figure having the incorrect letters written on the keys discourages me from looking down.

Anyway, the USB subsystem seems very readable for the higher level drvers and USB keeps getting more and more devices, so I'd recomed starting with a USB subsystem... too bad RadioShack is out of USB cue:cats :-D