|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|## page was renamed from KernelPatches|
|Line 47:||Line 48:|
|== How we will take it ==||== How to submit a patch to be included ==|
If you were sent to this URL, it's probably because you asked about including some patch into Ubuntu's kernel source. Most likely, you were sent here because the answer is "no", so here's the reasons why we can't or won't include the patch you requested.
- Patching stock code means we have to worry about merges between the patch and code it touches. This can happen while we are following upstream development of the kernel, or when doing security patches for released kernels.
- Patching stock code opens up to unforeseen security issues. The patch you are asking to include could contain potential security problems, which we would likely never hear about, since the code isn't part of the stock kernel.
- Patching stock code could introduce bugs that even users who aren't getting the features of the patch would see (Xen is a good example of this). Adding bugs is bad.
- Patching stock code means we can't get upstream kernel maintainers to help us much anymore. If our users experience bugs, we'll have to get them to try a stock kernel before being able to push the bug to upstream.
- Maintaining a patch in our tree is not easy. Let's say we include v0.54 of some patch. Later, we want to sync up to the latest version of this patch. It's not easy to simply revert v0.54, because merges could have changed some of the code. Not to mention, there are very few patches like this that provide incremental changes between versions.
- Most patches like this are not against a new enough kernel. For example, at the time of writing this, Xen was still only stable against 2.6.16, but the kernel we are working on is 2.6.20-pre. The 2.6.20 kernel line broke even our third-party drivers.
- "If it ain't good enough for Linus it ain't good enough for us." That's not 100% true, but the basic idea is that if the patch is not in upstream, that generally means they aren't stable. Ubuntu's kernel is not a testing ground for developing features.
- Confusion. This applies to patches that people want compiled as a separate kernel flavour. While we've done this for other features, it is not always good to have so many types of kernels available. Not to mention we'll also have people wanting flavour foo compiled with flavour bar, to provide a foo-bar kernel. We don't want to make a habit of this.
- A very uncommon reason, but just as important, is that the patch is just crap or serves no real purpose. Don't be offended.
- And the most important reason is, we just don't have time. Think if we included everyone's pet patch, and had to maintain them all. We'd be so swamped, we couldn't keep Ubuntu the great stable Linux OS it is now.
What can I do?
Some people seem to be able, and God help them, willing to maintain a kernel package outside of Ubuntu's main repository. This is great. I don't recommend it, but I don't try to dissuade people from taking this route.
Usually things happen in stages. Most custom kernels never make it past the first stage.
- People create custom kernels built against the Ubuntu source and provide it publicly somewhere. They take on all the responsibility of keeping it current.
- If the package is used enough, sometimes it can make it into Universe, and made available to a wider audience. The patch would build depend on the Ubuntu kernel source, and easily stay in sync with updates to it. It would also be built on all available architectures. For this to happen, takes a greater degree of commitment from the person maintaining this package.
- Hopefully, some time after this stage the patch will be included in upstream kernel. If not, then there's probably very little chance it would be included in the main Ubuntu kernel, but things can happen.
Colin: 1 & 2 would be much easier if building linux-restricted-modules against non-standard flavours were supported. I submitted some changes in a bug report but I don't think it has been looked at; wouldn't something similar go a long way towards facilitating kernel customization? --MattPrice
What will you take?
The sort of patches we do take are the ones that are very clean and touch little to no code in the stock source. Examples of this are:
- Modular code. Usually this is a driver that can simply be added to the build system (Makefile/Kconfig). We have a lot of this under the ubuntu/ subdirectory in the kernel source. The reasoning is that the code is usually only used by people that want it (either because they have the hardware the driver supports, or they manually load the module).
- Critical fixes. These would be patches against stock code, usually after the kernel we are using is released. If the kernel we are using is still in development, it is suggested you send the patch upstream so we get it by trickle down. Either way, sending the patch upstream is always a good idea.
There are probably some other cases. Usually, if you have to ask whether we would include it or not, the answer will be no.
How to submit a patch to be included
All patches must be submitted on firstname.lastname@example.org in one of two forms:
1) A pull request from a publicly available git repository, e.g., attach the output of 'git request-pull'. This is the preferred method for large or numerous patches.
2) From your local git repository run the command 'git format-patch -1 <SHA1>' and email the resulting file. Beware of tab mangling. Use an email attachment if necessary.
In all cases patches must have full provenance (including your Signed-off-by'), i.e., who wrote the patch, where it came from, and a descriptive commit log message. The kernel source tree has a full description of patch submission policies in 'Documentation/SubmittingPatches'.