How to patch the Linux kernel and download __linux for a specific version of the kernel

How to patch the Linux kernel
--------------------
Author: Jesper juhl,2005 year August
Date Last updated: 2006-01-05
Translator: Jeffshia, August 2006
Email:
Tshxiayu@126.com

One of the frequently asked questions in the Linux kernel mailing list is how to make a patch for the Linux kernel, or, more specifically,
There are so many backbones/branches, a patch in the end of which version of the underlying kernel to hit. I hope this document will explain to you that this
Point
In addition to explaining how to apply and uninstall patches, a different kernel tree is provided here (and how to make them special
Fix the patch) a brief introduction.
What is the meaning of the Linux kernel version number.
－－－－－－
All Linux cores contain three digits separated by dots. The first number is the core version. We are now the third edition (2.), some people may use the version number of 1 core, there may be a minority version of the 0 core.
The second number is the core's main number, and the main number (including 0) indicates stability. A stable version is generally represented by an even number, and an odd number represents an unstable version.
The last number is the second number. It is increased by every change. If you see the core version 2.0.8, you know it's core 2.0, the core of stability, it's been published for the nineth time (we're counting from zero).
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 by a diff application.
To get a patch right, you need to know which base version the patch is coming from and that the patch is going to
The current source code tree changes to what the new version is. This information may appear in the original data in the patch file, or it might
inferred from the filename.
How to make patches and uninstall patches
-------------------
You can use the patch program to make a patch. The patch program reads a diff (or patch) file, and then the file
The changed content of the description is applied to the code tree.
Patches in the Linux kernel are generated relative to the parent directory where the kernel source code directory is saved.
This means that the file path in the patch file contains the name of the kernel source file directory on which it is based (or like "a" and "B").
Other names, etc.).
Since this is likely to match the name of the kernel source code directory on your local machine (but for viewing a patch that doesn't have a label)
Based on the kernel version is very useful). You should switch to your kernel source code directory and remove patch when patching
The first component of the filename path in the file (the-P1 parameter of the patch command can complete this task).
To remove a previously patched patch, use the-r parameter to patch it.
So, if you use the following command to make a patch:
Patch-p1
Then you can uninstall the patch as follows:
Patch-r-P1
How can I add a patch/diff file to a patch.
-------------------------------------------
This can be done in a number of different ways (like Linux and other Unix-type operating systems).
In all of the examples below, I added this file (uncompressed) to the patch in the following syntax through standard input:
Patch-p1
If you just want to be able to follow the example and do not want to know the other patching method, then you can
Do not read the remainder of this section.
You can also use the patch-I parameter to get the name of the file, as follows:
Patch-p1-i path/to/patch-x.y.z
If your patch file is compressed using gzip or bzip2, then you don't have to decompress it before you use it, 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 unzip the patch file before patching, then you can gunzip the file
or BUNZIP2 operation---as follows:
Gunzip patch-x.y.z.gz
BUNZIP2 patch-x.y.z.bz2
This will give you an unformatted text patch-x.y.z file, at which point you can make this thing work the way you like it
The standard input or the-I parameter is added to the patch.
Some of the other better parameters are-s, which keeps patch out of output rather than output errors, which prevents errors from
Scrolling too fast on the screen. The--dry-run parameter allows the patch command to simply print out a list of the patch that will be hit
, without really making any changes. Finally,-verbose tells the patch command to print more information about the work in progress.
Common mistakes when patching
-------------------
When you use the patch command to make a patch, it tries to verify the integrity of the file in a different way.
Check that this file is a valid patch file and check that the code around these changes is not and provided
The context matches. These are just two of the most basic integrity checks made by patch.
If patch encounters something that looks wrong, then it has two options. It can refuse to apply these changes and
An abnormal interrupt or it is trying to find a way to make the patch command just make some minor changes.
An example of a patch trying to fix an error is that if all the contexts are matched, the changed rows match, but the rows
Line numbers do not match. This can happen, for example, if patch makes some changes in the middle of a file, but for some
Cause at the beginning of the file some rows were added or deleted. In this case, everything looks good and it only
is simply to move up and down a bit, when patch usually fixes these line numbers and hits the patch.
Any time you need to change some of the contents of a file as soon as the patch is patched, it tells you that:
This patch is a bit confusing. You should be wary of these changes, since even patches are likely to be properly
, but this is not always the case, and in some cases the result will be wrong.
When the patch command encounters a change that cannot be made up using a vague method, it will completely
Give up this action and leave a file with the. rej as the extension. You can read this file to see what is
What changes can't go on, and then fix it manually if you want.
If your kernel source code doesn't apply any third-party patches, just some patches from kernel.org, and you hit these patches
The order is correct, and you have not made any changes to these source files, then you should not see a patch
A vague change to the file or some rejection message. If you do see the news, then there will be a very high
Danger, which means that either your local source code book or the patch file is tainted in some way. In this case, you are likely
Is that the patch file should be downloaded again, and if things still remain the same, then I suggest you try to go from kernel.org
Download a complete new source code tree.
Let's take a look at more information that the patch might produce.
If the patch command stops and displays a "File to patch" prompt, then the patch command cannot find
The file to be patched. Most likely, you forget to specify the-P1 parameter or you are in a wrong directory. More not
One common scenario is that you'll find patches that need to be patched using-p0 parameters instead of-P1 parameters (read this patch file
Should be able to uncover this information-if so, this is a mistake made by the person who created the patch file, but not fatal.
If you get the information "Hunk #2 succeeded at 1887 with Fuzz 2 (offset 7 lines)", or is a similar
Message, that means the patch command must adjust the position of the change (in this case, it needs to move 7 lines to the place where it wants to patch
Adapt to this patch). The resulting file may or may not be correct, which is determined by the reason that the file is not the same as the desired file.
This often happens when you want to hit the patch generated in a different kernel version, this kernel version and the kernel that you're going to be playing patch based on.
Version is different.
If you get a message similar to "Hunk #3 FAILED at 2387", then this means that you can't properly hit this
Patches, and patch programs cannot be passed vaguely. This will produce a. rej file that causes patch to fail and produce a. Orig
The file shows you some of the original content that cannot be changed.
If you get the message: "Reversed (or previously applied) patch detected! Assume-r? [N] ",
Then patch detects that the changes contained in this patch file have been applied to the target file. If you've actually played before this
This patch and patch has encountered a bug, so you can simply choose [N]o and terminate this patch action. If you had previously
Patched and wanted to patch the previous version, but forgot to specify the-r parameter, then you can answer here [y]es to use patch
Restore it for you. This can also happen when the creator of the patch file inverts the location of the source file and the target directory when the patch file is created.
In this case the revert from the patch is actually a patch.
One similar to "Patch: * * * Unexpected end of file in patch" or "patch
Unexpectedly ends in Middle's line "means the patch command to join you in the
The document felt meaningless. Or your downloads are interrupted, and you try to hit a patch file without compressing it beforehand
Does not unzip it, or you use a patch file somewhere in the transmission by a mail client or a mail
The transport agent has been corrupted. For example, by dividing a long line into two rows. Usually these warnings can be done by putting these two
The separated lines are merged to solve.
As I mentioned above, if you're hitting a patch from kernel.org to a correct version,
And you have not modified the source tree, these errors will never happen. So if you come from kernel.org,
These bugs are on the patch, so you probably think you're either a patch file or a source tree.
The damage was lost. I suggest you restart the download of a complete kernel tree and the patches you want to make.
Is there a substitute for patch?
-----------------
Yes, there are some alternatives.
You can use the "Interdiff" program (
http://cyberelk.net/tim/patchutils/
) to produce a file to represent
Two patch files between the differences and then hit this file. This can make you a step from a version like 2.6.12.2
You can reach version 2.6.12.3. The-Z flag even allows you to give Interdiff some use gzip or bzip2 compressed
Format files without using Zcat or Bzcat or manual decompression.
Here's how you can get from 2.6.12.2 to 2.6.12.3 in one step
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 recommend that you normally do these additional steps,
This is because in some cases interdiff will mess things up.
Another alternative is "ketchup", a script written in Python that can automatically download and
Make some patches (
http://www.selenic.com/ketchup/
).
Other good tools are Diffstat, which shows a summary of all the changes made by patch; Lsdiff, you can show
A short list of the affected files in a patch file, and (optionally) a line number for each patch; Grepdiff, but
To display a list of files that are modified by a patch file when the patch contains a given regular expression.
I can download these patches from where.
-----------------------
Patch files can be from
http://kernel.org/
To obtain
Recent patch files can be obtained from the links on the home page, but they also have their own specific homepage.
2.6.X.Y (-Stable) and 2.6.x patches are located at:

ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
The-RC patch is located at:

ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/
The-git patch is located at:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/
-MM kernel patches are located at:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
In
ftp.kernel.org
In which you can use
ftp.cc.kernel.org
, where CC is a country code. So you can get from a
Download the mirror sites that are geographically closer to you, allowing you to get faster downloads, less bandwidth globally, and
Smaller pressure on the kernel.org primary server---This is a good thing, so you still use these mirrors when possible.
Site.
2.6.x kernel
---------
This is the underlying stable version of Linus release. The highest version of the release is up to date.
If a conflict or serious flaw is found, a-stable patch will be released on this basis.
Come out (see below). Once a new 2.6.x base kernel is released, a beta version of the patch can be obtained
, this patch is based on the previous 2.6.x version of the kernel and the new kernel.
In order to apply a patch from 2.6.11 to 2.6.12, you'd better do the following (note that these patches are not applied to the 2.6.X.Y kernel,
Instead, it is applied to the base kernel of 2.6.x---if you need to 2.6.x.y to 2.6.x+1, then you first need to uninstall the 2.6.x.y patch)
Here are some examples:
#从2.6.11 to 2.6.12
$ cd ~/linux-2.6.11 # switch to Kernel source code directory
$ patch-p1
# moving from 2.6.11.1 to 2.6.12
$ cd ~/linux-2.6.11.1 # switch to Kernel source code directory
$ patch-p1-r
2.6.X.Y kernel
-----------
The kernel with a four-digit version number is the-stable kernel. They contain some security for a given 2.6.x kernel
Problems as well as the restoration of important degradation found.
For those who want the most recent stable kernel and are not interested in the experimental version of the test development
For users, we recommend this branch.
If there is no 2.6.x.y kernel available, the 2.6.x kernel with the highest number is the current stable kernel.
Note: Teams that maintain a stable kernel typically do some incremental patches, as if they were based on the most recent major release
Patch like that. But below I just explained the non increment situation. Those incremental versions can be in the following FTP
To find:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/incr/
.
These patches are not incremental, meaning that for example, a 2.6.12.3 Patch cannot be applied to 2.6.12.2 kernel source code
Up, but it can be applied to the 2.6.12 kernel code.
Therefore, in order to apply the 2.6.12.3 patch to the kernel source code of the 2.6.12.2 you are using, you have to uninstall
2.5.12.2 Patch (so you can get a base of the 2.6.12 kernel source code) and apply the new 2.6.12.3 Patch.
Here is a small example:
$ cd ~/linux-2.6.12.2 # switch to Kernel source code directory
$ patch-p1-r
-RC kernel
-------
These are the candidate release cores. When Linus believes that the current git (Kernel source control tool) kernel tree is in a
A robust stable state is sufficient for testing when the development kernel is released.
These cores are unstable, and if you try to run they should think that there may be problems that might arise occasionally.
But this is the most stable kernel on the main development branch and will eventually become the next stable kernel. So
It is particularly important to have as many people as possible to test it.
For those who want to help test the kernel of the development but do not want to run those experimental things, it will be
A very good branch. (Such people should refer to the following section on the-git and-mm cores)
-RC patches are not incremental, they apply 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.
So, 2.6.13-rc5 means this is the fifth release version of the 2.6.13 kernel, and this patch should hit
2.6.12 on the kernel source code.
Here are 3 examples of how to make these patches:
# The first is an example from 2.6.12 to 2.6.13-RC3
$ cd ~/linux-2.6.12 # switch to 2.6.12 's source code directory
$ patch-p1
# now migrating from 2.6.13-RC3 to 2.6.13-RC5
$ cd ~/LINUX-2.6.13-RC3 # switch to 2.6.12 's source code directory
$ patch-p1-r
# Finally, let's try to get from 2.6.12.3 to 2.6.13-RC5
$ cd ~/linux-2.6.12.3 # switch to Kernel source code directory
$ patch-p1-r
-git kernel
--------
These are snapshots of the daily Linus Kernel tree (managed in a git repository, hence the name).
These patches are usually released daily and represent the current state of the Linus kernel tree, as they are automatically generated
Even without the commotion of any of the cursors to see whether they are sound, they are more experimental than the-RC kernel.
-git patches are not incremental, they are either applied to the 2.6.x kernel or are applied to a base
2.6.X-RC The kernel---you can see it from their names. A name is 2.6.12-git1.
Patches are applied to the 2.6.12 kernel source code, and a patch named 2.6.13-rc3-git2 is applied to the 2.6.13-RC3
On the kernel source code.
Here are some examples of how to make these patches:
# Migrating from 2.6.12 to 2.6.12-git1
$ cd ~/linux-2.6.12 # switch to Kernel source code directory
$ patch-p1
# Migrating from 2.6.12-git1 to 2.6.13-rc2-git3
$ cd ~/linux-2.6.12-git1 # switch to Kernel source code directory
$ patch-p1-r
-MM kernel
-------
This is an experimental kernel released by Andrew Morton.
-mm Tree as a new feature and experimental patch of the experimental field. Once a patch has been proven in the-mm for some time
Valuable, and in order for it to be included in the mainstream kernel, Andrew would push it to Linus.
Although the method of encouragement is to push the patch to Linus through the-mm tree, this step is not always implemented. The maintainer of the subsystem
Sometimes the patches are pushed directly to the Linus, although (or later) they have been and have been-mm
To the test (or sometimes not to be tested beforehand in-mm).
Usually you should try to get your patch through the-mm to the main kernel after the maximum test.
This branch is a continuous change and contains some experimental features, and many of the patches being debug are not suitable for
Mainstream kernel, and so on. This branch is the most experimental branch described in this document.
These kernel cores are not suitable for applications that require a stable system, and are more likely to be held in operation than any other branch
Greater risk (make sure you have the latest backup---this applies to any of the experimental kernels, but this is more required for the-MM kernel).
In addition to incorporating all of the experimental patches, these cores also contain any of the major-git kernel releases
Changes that are available.
The-MM kernel test is greatly appreciated, because the overall purpose of this branch is to be added to a more stable
Before the mainstream Linus kernel tree, eliminate degradation, panic, data failure bugs, build failures (and any usual bugs).
But-mm testers should be aware that the failure in the source tree is more prevalent than in any other tree.
The-MM kernel will not be released at a fixed time, but usually some-mm cores will be in each-RC kernel (usually 1 to 3)
Published in the middle. The-MM kernel is either applied to a base 2.6.x kernel (when there is no-RC kernel release) or is applied to
A LINUS-RC kernel.
Here's an example of a dozen-mm patches
# from 2.6.12 to 2.6.12-MM1
$ cd ~/linux-2.6.12 # switch to 2.6.12 's source file directory
$ patch-p1
# from 2.6.12-MM1 to 2.6.13-RC3-MM3
$ CD ~/LINUX-2.6.12-MM1
$ patch-p1-r
Some explanations for different kernel trees are summarized above. I hope you've figured out how to make a different patch and test it for you.
Testing the kernel helps.
List of credits:
Randy Dunlap, Rolf Eike Beer, Linus Torvalds, Bodo Eggert,
Johannes Stezenbach, Grant Coady, Pavel Machek, and some people I may have forgotten their names,
But they have commented or contributed to the document.