Abstract

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

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

Alan Cox

Kernel hacking may not be hard, but it certainly could not be described as easy. That said, probably the biggest barrier to be overcome is a psycological one; having the confidence to get started, dive in and try things out. The next barrier to be faced is the lack of up to date, organised documentation, which 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 code, it is all very disparate, dis-organised and on occasion even 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 interests them.
• Those who would like to get involved in kernel development but don't have time to figure everything out from scratch.
• 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.
• Explaining by practical demonstration where possible.
• Providing enough information to get started in important areas.
• Supplying pointers to 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 and are looking for something more challenging!

Prerequisites

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. There are good reasons why you should be prepared to work at the console; these will be explained later (it is also considered "the hackers way" to do things).
• The ability to compile you own kernel. If you have not done this before 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. (Don't be deceived though, learing to program takes a lot longer than 21 days!) Alternatively you can find good C tutorials on-line at the Open Directory Project.
• Some background knowledge of computer hardware and operating systems is useful but not essential. Suggested reading in this area is given in the books section of this document.

Copyright

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

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! News

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

• SGML source
• HTML to read on-line
• tar'ed multi-page HTML
• gzipped text

The SGML source is updated most frequently. The other formats only get updated for major new releases or when I feel the changes warrant the hassle. Credits

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

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: kh.howto@clara.co.uk

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

• HOWTO QUESTION for any HOWTO related questions or to suggest an FAQ entry.
• KH HOWTO RFC for any "request for change" type suggestions.
• KH HOWTO BUG for any factual error or bug reports.
• KH HOWTO TYPO for typo corrections.
• KH HOWTO CONTRIB to submit a new section. (patch against latest SGML preferred.)
• KH HOWTO SUGGEST to make a suggestion. (please check TO DO section at end of document first.)
• KH HOWTO GLOSSARY to make a submission for the glossary.
• KH HOWTO FEEDBACK for general feedback.
• KH HOWTO for any other HOWTO related correspondence.

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.