Kernel Hacking HOWTO

Andrew Ebling

Revision History
Revision 0.16 2002-1-17 ajme
Complete read thru following a good break, spell & grammar review, added abstract, revised Introduction and prerequisites, new email address, added some FAQs, added "Your Turn" sections.
Revision 0.15 2001-12-25 ajme
Conversion to DocBook 3.1 SGML to make maintaining the glossary less time consuming, full spell check and a lot of small fixes and improvements.
Revision 0.14 2001-12-16 ajme
Started glossary, lots of small fixes.
Revision 0.13 2001-12-05 ajme
Added "Boot time Parameters" section in "General Hacking", CVS section added in tools chapter, "The Linux Kernel Development Cycle" section started, more URLs added and lots more small fixes.
Revision 0.12 2001-12-04 ajme
Emacs section added in tools chapter, lots more small fixes.
Revision 0.11 2001-12-01 ajme
Conversion to SGML, fixing it up to be like an LDP HOWTO plus numerous small fixes.
Revision 0.10 2001-11-25 ajme
Initial release.

Table of Contents

Who this document is for
Why hack the kernel?
Contacting the Author
Linux Kernel Overview
Kernel Modes
Signals and Inter Process Communication
Memory Management
Virtual File system
Disk Caches
Your Turn
Source Tour
What goes where
Key data structures
Starting Points
Your Turn
Source Code Navigation
Source Code Manipulation
Your Turn
General Kernel
General Hacking
Bug Hunting
Basic Functions
Drivers & Modules
Kernel Debugging
When things go wrong
Oops Analysis
Using a Debugger
The Debugging Session
Misc. Notes
Using the logs
Profiling & Benchmarking
Why profile?
Basic profiling
The Linux Kernel Development Cycle
Stable Series
Unstable Series
Feature Freezes
Code Freezes
Intermediate Patches
Your Turn
Coding Tips
General Development Tips
More Information
Source code docs
Getting Help
mailing lists
To Do
References & Acknowledgments


This document is a structured record of my own journey, from a relatively inexperienced application programmer to an even more inexperienced kernel programmer. By sharing my experience, I hope to make kernel hacking more accessible to other members of the open source community.


<attributation>Alan Cox on advice for new hackers, in an interview on with Jeremy Andrews</attributation>

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.

Kernel hacking may not be hard, but it certainly could not be described as easy. The lack of up to date, organised and comprehensive documentation hampers the efforts of even the most determined. Although there is actually quite a lot of information out there in books, web pages, newsgroups, mailing lists and the source itself, it is all very disparate, disorganised and on occasion contradictory.

This document aims to address this issue. Hopefully it will attract bright new talent to the Linux Kernel Community. One day, someone will have to take over from Linus!

Who this document is for

This document is aimed at:

  • Those who are confident compiling the Linux kernel, would like to contribute to it's development, but feel intimidated by the 2 million lines of kernel source code.

  • Those who want to find out if kernel programming is of interest.

  • Those who would like to get involved in kernel development but don't have time to figure everything out for themselves.

  • Those who want to improve their kernel programming productivity.

It aims to accelerate the learning process by:

  • Bringing together into one place as much key information as possible.

  • Providing "the basics" in key areas.

  • Supplying pointers to more in-depth information.

Why hack the kernel?

Some reasons why people get into kernel programming:

  • They find the current kernel inadequate in some way and want to help fix the problem, perhaps by writing a new device driver or by working on improving the performance of one of the kernel's subsystems.

  • They want to learn how a real operating system works, as opposed to the vague, high level concepts taught on most computer architecture courses.

  • They like Linux and want to contribute to its development.

  • They find application programming too easy or boring and are looking for something more challenging!


What should I know before I start working through this document?

  • A fair amount of Linux experience from a user/developer perspective. If you are happy to use the console rather than X-windows to do most of your development work, you are probably ready.

  • The ability to compile you own kernel. If this does not include you then read, understand, follow and commit to memory the steps given in the Kernel-HOWTO.

  • A good, working knowledge of the C programming language. If this does not include you, why not start learning now? There are many good books on C, some of which are well suited to home/self learning e.g. SAMS Publishing "Teach Yourself in 21 Days/24 Hours" series. Alternatively you can find good C tutorials online at google groups.

  • Some background knowledge of computer hardware and operating systems is useful but not essential.


Copyright (c) 2001/2002 Andrew Ebling

Please freely copy and distribute (sell or give away) this document in any format. It's requested that corrections and/or comments be forwarded to the document maintainer. You may create a derivative work and distribute it provided that you:

  • Send your derivative work (in the most suitable format such as SGML) to the LDP (Linux Documentation Project) or the like for posting on the Internet. If not the LDP, then let the LDP know where it is available.

  • License the derivative work with this same license or use GPL. Include a copyright notice and at least a pointer to the license used.

  • Give due credit to previous authors and major contributors.

If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer.


Use the information in this document at your own risk. I disavow any potential liability for the contents of this document. Use of the concepts, examples, and/or other content of this document is entirely at your own risk.

All copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.

Naming of particular products or brands should not be seen as endorsements.

You are strongly recommended to take a backup of your system before modifying the kernel and make backups at regular intervals. If you would miss it if you lost it, back it up!


The latest version of this document will be available at the web site in a number of formats:

The SGML source gets updated most frequently (i.e. whenever I have five minutes to spend on the document), the other formats only get updated for major new releases or when I feel the changes warrant the hassle.


I have the pleasure of acknowledging contributions from the following people:

  • Adam Keys for his emacs contribution.

  • Bruce Blinn for his CVS contribution.

  • Rik van Riel for technical corrections.

  • Jason Copenhaver, Guillaume Morin, Tero Kuusela, Tom Bradley for typos and grammar corrections.

  • Igor Gilitschenski, Bohdan Vlasyuk, Tero Kuusela, Florian Zimmermann for general feedback, encouragement and suggestions.

If you contributed a typo or grammar correction and your name is not in this list, it probably means that the error had already been reported and fixed. If you reported a problem that has not been fixed in the current version of this document, please re-send your bug report adding REPEAT to the subject line. I do my best to attend to all the reports I get sent, but occasionally something slips through the net.


As yet there are no translations of this document. Translations are welcome, but please contact me first.

Translation volunteers to date:

  • Paulo Andre has offered to translate the document into Portuguese.

Contacting the Author

Any comments or suggestions can be mailed to me:

Please note that I am likely to be changing ISPs soon, so be sure to check the latest version of this document to get a "live" email address.

Please use these subject line conventions (in addition to your own short and concise subject) to help me handle queries efficiently and filter SPAM:

I ruthlessly filter on subject, so any emails not following these conventions may silently/automatically get deleted. Subject lines like "Hi!", "hello", "your website" etc. are usually spam so are likely to get deleted without getting read. Thank you for understanding and co-operation.