| 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
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 http://www.kerneltrap.com 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!
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:
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 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.
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:
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:
Any comments or suggestions can be mailed to me: kh.howto@clara.co.uk
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:
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 SUGGEST 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.