How to patch Linux Kernel

A frequently asked question in the Linux Kernel mailing list is how to patch the Linux kernel or, more specifically,
There are so many trunk/branches that a patch must be installed on the basic kernel. I hope this document will help you understand this
A little.
In addition to explaining how to apply and uninstall patches, a different kernel tree is provided here (and how to attach a special
Patches.

What is a patch?
----------
A patch is a text document that contains changes between two different versions of the source code tree.
Patches are created through the diff application.
In order to install a patch correctly, you need to know which base version the patch is generated and the patch will
The new version of the current source code tree. This information may appear in the original data of the patch file, or possibly
It can be inferred from the file name.

How to install and uninstall Patches
-------------------
You can use the patch program to create a patch. The patch program reads a diff (or patch) file and
The changed content of the description is applied to the code tree.

The patches in the Linux kernel are generated relative to the parent directory that saves the kernel source code directory.
This means that the file path in the patch file contains the name of the kernel source file directory it is based on (or such as "A/" and "B /"
And so on ).

This may not match the name of the kernel source code directory on your local machine.
Based on the kernel version is very useful ). You should switch to your kernel source code directory and remove the patch when patching.
(The-P1 parameter of the patch command can complete this task ).
To uninstall a previously installed patch, use the-R parameter.
Therefore, if you use the following command to install patches:
Patch-P1 <../patch-x.y.z
You can uninstall the patch as follows:
Patch-r-P1 <../patch-x.y.z

How can I add a patch/diff file to a patch?
-------------------------------------------

This can be done in many different ways (like Linux and other UNIX-like operating systems ).
In all the examples below, I add the following syntax of this file (uncompressed) to the patch through standard input:
Patch-P1 <path/to/patch-x.y.z
If you just want to follow the example below and do not want to know other patching methods, then you can
I will not read the contents of this savings.
You can also obtain the file name through the patch-I parameter, as shown below:
Patch-P1-I path/to/patch-x.y.z

If your patch file is compressed using gzip or Bzip2, you do not need to decompress it before use. You can
Add it to the patch file as follows:
Zcat path/to/patch-x.y.z.gz | patch-p1
Bzcat path/to/patch-x.y.z.bz2 | patch-p1
If you want to manually decompress the patch file before patching, you can perform gunzip
Or the bunzip2 operation --- as follows:
Gunzip patch-x.y.z.gz
Bunzip2 patch-x.y.z.bz2
This will give you a non-formatted text patch-x.y.z file, at this time you can put this thing in the way you like
Standard input or-I parameters are added to the patch.
Some other better parameters are-S. This parameter keeps the patch from output rather than output errors, which will prevent errors in
The scrolling speed on the screen is too fast. -- The dry-run parameter allows the patch command to print only a list of patches to be played.
, Without any real changes. Finally,-verbose tells the patch command to print more information about the ongoing work.

Common Errors During Patching
-------------------

When you use the patch command to install a patch, it tries to verify the integrity of the file in different ways.
Check whether this file is a valid patch file and whether the code around the changed file is provided or not.
Context match. These are only the two most basic integrity checks performed by the patch.
If a patch encounters something that seems incorrect, there are two options. It can reject these changes and
Exception interruption or it tries to find a method to make the patch command only make some minor changes.

An example of a patch trying to correct an error is: if all the context matches, the changed rows match, but
The row number does not match. This may happen. For example, if the patch changes in the middle of a file
The reason is that some lines at the beginning of the file are added or deleted. In this case, everything looks good, it only
The patch usually fixes these row numbers and adds the patch.
At any time, as long as the patch needs to modify some content of the file during patching, it will tell you:
This patch is a bit messy. You should be cautious with these changes, even if the patch is likely to be correct.
But this is not always the case. In some cases, the result will be wrong.
When the patch command encounters a change and cannot be compensated by a fuzzy method, It will completely
Discard this action and leave a file with the. rej extension. You can read this file to check whether
What changes cannot be made, so you can manually fix them if you want.

If no third-party patches are applied to your kernel source code, but some patches are from kernel.org, and you apply these patches
The order is correct, and you have not modified these source files, then you should not see a patch
Blur the file or reject messages. If you see these messages, they will be very high.
Dangerous. This indicates that your local source code book or patch file is corrupted in some ways. In this case, you are likely
We recommend that you download the patch again.
Download a complete new source code tree.
Let's take a look at more information that the patch may generate.

If the patch command stops and a "file to patch" prompt is displayed, the patch command cannot be found at this time.
The file to be patched. It is very likely that you forgot to specify the-P1 parameter or you are in an incorrect directory. Even more
One common situation is that you will find that some patches need to be patched using the-P0 parameter instead of the-P1 parameter (read this patch file ).
It should be able to reveal this information-If so, this is an error made by the person who created the patch file, but it is not fatal)
If you get the information "Hunk #2 succeeded at 1887 with Fuzz 2 (offset 7 lines)", or a similar
The patch command must adjust the changed location (in this example, it needs to move seven lines where it wants to patch ).
Adapt to this patch ). The obtained file may be correct or incorrect, which is determined by the reason that the file is different from the expected file.
This often happens when the patch you want is generated in another kernel version, which is based on the kernel
Different versions.
If you get a message similar to "Hunk #3 failed at 2387", it means that you cannot properly attach this
Patch, and the patch program cannot pass through fuzzy. This will generate a. rej file that causes patch failure and generate a. orig
The file displays some unmodifiable raw content to you.
If the information you get is: "reversed (or previusly applied) patch detected! Assume-r? [N] ",
The patch detects that the changes in the patch file have been applied to the target file. If you have already played
If you encounter an error when patching the patch again, you can simply select [N] o and terminate the patch. If you
If you have installed a patch and want to install the patch in the previous version, but forget to specify the-R parameter, you can answer [y] es here to use the patch.
Restore it for you. This may also happen when the creator of the patch file places the source file and target directory upside down when creating the patch file,
In this case, the revert in the patch is actually installed with this patch.
It is similar to "patch: *** unexpected end of file in patch" or "patch
The message of unexpectedly ends in middle of line means that the patch command is added to it
The file is meaningless. Or your download is interrupted. You try to create a patch file that is not compressed.
It is not decompressed, or the patch file you are using is sent by an email client or an email somewhere.
The transmission proxy is damaged. For example, a long row is divided into two rows. In general, these warnings can be handled
Separate rows are merged to solve the problem.
As I mentioned above, if you are using a patch from kernel.org to a correct version,
And you have not modified the source code tree. These errors will never happen. So if you come from kernel.org
If these errors are reported on the patch, you may think that it is your patch file or source code tree.
Damaged. I suggest you download a complete kernel tree and the patch you want again.

Is there a patch alternative?
-----------------
Yes, there are some alternatives.

You can use the "interdiff" Program (http://cyberelk.net/tim/patchutils/) to generate a file to represent
The difference between the two patch files, and then append the file. This allows you to step from a version like 2.6.12.2.
You can get to version 2.6.12.3. The-Z mark can even be used to send interdiff some files compressed using gzip or Bzip2.
Format File instead of zcat or bzcat or manually decompress it.
Next we will show you how to get from 2.6.12.2 to 2.6.12.3.
Interdiff-Z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch-p1
Although interdiff can save one or two steps, I suggest you perform these additional steps normally,
This is because interdiff may make things worse in some cases.

Another alternative is ketchup, which is a script written in Python that can be automatically downloaded and
Install some patches (http://www.selenic.com/ketchup ).

Another good tool is diffstat, which can display the summary of all changes made by the patch; lsdiff, which can be displayed
A brief list of affected files in a patch file, and (optional) The line number of each patch; grepdiff, can
To display a list of files modified by the patch file when the patch contains a given regular expression.

Where can I download these patches?
-----------------------

Patch files can be obtained from http://kernel.org/
Recent patch files can be obtained from the home page link, but they also have their own specific home page.
2.6.x.y (-stable) and 2.6.x Patch are located:
Ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
-The RC patch is located:
Ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/
-The GIT patch is located:
Ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/
-Mm kernel patch is located:
Ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
In ftp.kernel.org, you can use ftp.cc.kernel.org. CC is a country code. In this way, you can
By downloading the image site that is geographically close to you, you can get faster download speeds, less global bandwidth, and
It is a good thing to put less pressure on the kernel.org master server, so you can still use these images whenever possible.
Site.

2.6.x Kernel
---------
This is the latest basic stable version released by Linus.

If a conflict or serious defect is found, a-stable patch will be released on this basis.
). Once a new 2.6.x basic kernel is released, you can obtain a patch for the beta version.
The patch is based on the 2.6.x kernel and the new kernel.

To apply a patch from 2.6.11 to 2.6.12, you 'd better follow the steps below (note that these patches cannot be applied to the 2.6.x.y kernel,
Instead, it is applied to the basic kernel of 2.6.x. If you need to upgrade from 2.6.x.y to 2.6.x + 1, you must first uninstall the 2.6.x.y patch)
The following are some examples:

# From 2.6.11 to 2.6.12
$ Cd ~ /Linux-2.6.11 # Switch to the kernel source code directory
$ Patch-P1 <../patch-2.6.12 # apply 2.6.12 patch
$ CD ..
$ MV linux-2.6.11 linux-2.6.12 # rename source code directory
# Moving from 2.6.11.1 to 2.6.12
$ Cd ~ /Linux-2.6.11.1 # Switch to the kernel source code directory
$ Patch-P1-r <../patch-2.6.11.1 # restored 2.6.11.1
# The Source Code directory is 2.6.11
$ Patch-P1 <../patch-2.6.12 # apply the new 2.6.12 patch
$ CD ..
$ MV linux-2.6.11.1 linux-2.6.12 # rename source code directory

2.6.x.y Kernel
-----------
The kernel with four digit version numbers is the-stable kernel. They include some security for a given 2.6.x Kernel
Problems and important degradation fixes.

Those who want the latest stable kernel and are not interested in testing and developing experimental versions
For users, we recommend this branch.
If no 2.6.x.y kernel is available, the 2.6.x kernel with the highest number is the current stable kernel.

Note: The team that maintains the stable kernel usually performs some incremental patches, such as the latest major version release.
. But below I will only explain the non-incremental situation. The incremental versions can be found in the following FTP
The ftp://ftp.kernel.org/pub/linux/kernel/v2.6/incr.

These patches are not incremental, meaning that for example, 2.6.12.3 patches cannot be applied to 2.6.12.2 kernel source code.
But it can be applied to kernel code 2.6.12.
Therefore, to apply the 2.6.12.3 patch to the kernel source code of 2.6.12.2, You Have To uninstall it.
2.5.12.2 patch (so you can get a basic 2.6.12 kernel source code) and apply the new 2.6.12.3 patch.

Below is a small example:
$ Cd ~ /Linux-2.6.12.2 # Switch to the kernel source code directory
$ Patch-P1-r <../patch-2.6.12.2 # regression 2.6.12.2 patch
$ Patch-P1 <../patch-2.6.12.3 # apply the new 2.6.12.3 patch
$ CD ..
$ MV linux-2.6.12.2 linux-2.6.12.3 # rename kernel source code directory

-RC Kernel
-------
These are candidate release kernels. When Linus considers the current git (kernel source code management tool) kernel tree to be in
Sound and stable status is enough for testing, and the Development kernel is released.

These kernels are unstable. If you try to run them, they may think of problems from time to time.
But this is the most stable Kernel on the main development branch and will eventually become the next stable kernel. Therefore
It is especially important to have as many people as possible to test it.

For those who want to help test the development kernel but do not want to run those experimental things, this will be
A very good branch. (Such a person should refer to the following section about-Git and-mm kernel)
-RC patches are non-incremental and applied to the 2.6.x kernel, just like the 2.6.x.y kernel described above. In-RCN
The kernel version number before the suffix represents the kernel version that the-RC kernel will eventually become.
Therefore, 2.6.13-RC5 indicates that this is the fifth candidate release version of Kernel 2.6.13, and this patch should be installed in
2.6.12 kernel source code.

The following are three examples of how to install these patches:
# The first example is from 2.6.12 to 2.6.13-RC3.
$ Cd ~ /Linux-2.6.12 # Switch to the 2.6.12 source code directory
$ Patch-P1 <../patch-2.6.13-rc3 # patch 2.6.13-RC3
$ CD ..
$ MV linux-2.6.12 linux-2.6.13-rc3 # rename the source directory
# Migrating from 2.6.13-RC3 to 2.6.13-RC5
$ Cd ~ /Linux-2.6.13-rc3 # Switch to the 2.6.12 source code directory
$ Patch-P1-r <../patch-2.6.13-rc3 # uninstall 2.6.13-RC3 patch
$ Patch-P1 <../patch-2.6.13-rc5 # apply the new 2.6.13-RC5 patch
$ CD ..
$ MV linux-2.6.13-rc3 linux-2.6.13-rc5 # rename the source directory
# Finally, let's try from 2.6.12.3 to 2.6.13-RC5
$ Cd ~ /Linux-2.6.12.3 # Switch to the kernel source code directory
$ Patch-P1-r <../patch-2.6.12.3 # Return to 2.6.12.3 patch
$ Patch-P1 <../patch-2.6.13-rc5 # apply the new 2.6.13-RC5 patch
$ CD ..
$ MV linux-2.6.12.3 linux-2.6.13-rc5 # rename the source directory

-Git Kernel
--------
These are Linux kernel tree snapshots (managed in a git repository, hence the name ).
These patches are usually released every day and represent the current status of the Linus kernel tree, because they are automatically generated.
There wasn't even any cursor turmoil to see if they were sound, so they were more experimental than the-RC kernel.

-Git patches are not incremental. They are applied on the 2.6.x kernel or on a basic
2.6.x-RC kernel-you can see this in their names. One name is 2.6.12-git1
Patch application on 2.6.12 kernel source code, a patch application named 2.6.13-rc3-git2 on 2.6.13-RC3
.

Here are some examples of how to apply these patches:
# Migrate from 2.6.12 to 2.6.12-git1
$ Cd ~ /Linux-2.6.12 # Switch to the kernel source code directory
$ Patch-P1 <../patch-2.6.12-git1 # apply 2.6.12-git1 patch
$ CD ..
$ MV linux-2.6.12 linux-2.6.12-git1 # rename kernel source code directory
# Migrate from 2.6.12-git1 to 2.6.13-rc2-git3
$ Cd ~ /Linux-2.6.12-git1 # Switch to the kernel source code directory
$ Patch-P1-r <../patch-2.6.12-git1 # Return 2.6.12-git1 patch
# Now we have a 2.6.12 Kernel
$ Patch-P1 <../patch-2.6.13-rc2 #