Updated link to "The Perfect Patch"
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 25:||Line 25:|
| * ["/MergingStrategy"] strategies for merging code upstream.
* ["/WhatNotToDo"] what you should never do if you want to merge upstream.
* ["/GettingFlamed"] Oh no! The kernel developers said bad things about me, my code and my cat! What do I do now?
| * [[/MergingStrategy]] strategies for merging code upstream.
* [[/WhatNotToDo]] what you should never do if you want to merge upstream.
* [[/GettingFlamed]] Oh no! The kernel developers said bad things about me, my code and my cat! What do I do now?
|Line 30:||Line 30:|
| * ["/SubmittingDrivers"] how to submit device drivers to the linux kernel.
* ["/SubmittingPatches"] how to submit patches to the linux kernel.
* ["/SubmitChecklist"] a checklist for submitting code upstream.
| * [[/SubmittingDrivers]] how to submit device drivers to the linux kernel.
* [[/SubmittingPatches]] how to submit patches to the linux kernel.
* [[/SubmitChecklist]] a checklist for submitting code upstream.
|Line 35:||Line 35:|
| * [http://linux.yyz.us/patch-format.html]
* [https://www.ozlabs.org/~akpm/stuff/tpp.txt] The Perfect Patch
* [http://linuxdriverproject.org/twiki/bin/view/Main/WebHome The Linux Driver Project]
| * [[http://linux.yyz.us/patch-format.html]]
* [[https://www.ozlabs.org/~akpm/stuff/tpp.txt]] The Perfect Patch
* [[http://linuxdriverproject.org/twiki/bin/view/Main/WebHome|The Linux Driver Project]]
This section of the Kernelnewbies site is meant as a guide on how to get code merged into the upstream kernel, the kernel tree managed by Linus Torvalds and available from kernel.org.
What are the benefits of merging code upstream?
Merging your source code upstream takes effort, dedication and time. The process is not easy, because the moment Linus accepts code into his tree, he runs the risk of having to maintain that code for the rest of his life. If bad quality code got accepted, maintaining the Linux kernel would become much more difficult. These reasons and more mean that the threshold for getting source code accepted into the Linux kernel is relatively high.
However, there are also a number of benefits to having your source code accepted into the kernel.
Keeping up with the changes in the upstream kernel can be a challenge, wasting days or weeks of developer time every time the upstream kernel changes. Code that lives in the upstream kernel does not have this issue, since kernel developers tend to simply grep the sources and fix up any driver that is impacted by a proposed API change. This frees up your developers for more important work.
Your source code will be present in every Linux distribution. This matters if you would like to sell your hardware to every Linux user. No more need to lobby distributions to include your patches (hard), you can just ask them to switch on a config option (easy).
Some of the world's best developers will be going over your source code with a fine comb. This may be embarrassing for a few days or weeks, but in the end the code tends to work better and be more easily maintained. In some cases the upstream developers have made network and storage drivers 30% faster, making the hardware more attractive to customers.
How to merge code upstream
Merging code into the upstream kernel can be a daunting process to the uninitiated. However, with the right strategy in mind, you won't get lost on your way to upstream acceptance.
/MergingStrategy strategies for merging code upstream.
/WhatNotToDo what you should never do if you want to merge upstream.
/GettingFlamed Oh no! The kernel developers said bad things about me, my code and my cat! What do I do now?
Helpful documents from the kernel tree:
/SubmittingDrivers how to submit device drivers to the linux kernel.
/SubmittingPatches how to submit patches to the linux kernel.
/SubmitChecklist a checklist for submitting code upstream.
Other documents on getting patches upstream:
https://www.ozlabs.org/~akpm/stuff/tpp.txt The Perfect Patch