A guide to the Kernel Development Process

Contents:

• 1. Introduction
  • 1.1. Executive summary
  • 1.2. What this document is about
  • 1.3. Credits
  • 1.4. The importance of getting code into the mainline
  • 1.5. Licensing
• 2. How the development process works
  • 2.1. The big picture
  • 2.2. The lifecycle of a patch
  • 2.3. How patches get into the Kernel
  • 2.4. Next trees
  • 2.5. Staging trees
  • 2.6. Tools
  • 2.7. Mailing lists
  • 2.8. Getting started with Kernel development
• 3. Early-stage planning
  • 3.1. Specifying the problem
  • 3.2. Early discussion
  • 3.3. Who do you talk to?
  • 3.4. When to post?
  • 3.5. Getting official buy-in
• 4. Getting the code right
  • 4.1. Pitfalls
  • 4.2. Code checking tools
  • 4.3. Documentation
  • 4.4. Internal API changes
• 5. Posting patches
  • 5.1. When to post
  • 5.2. Before creating patches
  • 5.3. Patch preparation
  • 5.4. Patch formatting and changelogs
  • 5.5. Sending the patch
• 6. Followthrough
  • 6.1. Working with reviewers
  • 6.2. What happens next
  • 6.3. Other things that can happen
• 7. Advanced topics
  • 7.1. Managing patches with git
  • 7.2. Reviewing patches
• 8. For more information
• 9. Conclusion

The purpose of this document is to help developers (and their managers) work with the development community with a minimum of frustration. It is an attempt to document how this community works in a way which is accessible to those who are not intimately familiar with Linux kernel development (or, indeed, free software development in general). While there is some technical material here, this is very much a process-oriented discussion which does not require a deep knowledge of kernel programming to understand.