Linux beginner's Patch User Guide

Linux Patch User Guide-general Linux technology-Linux programming and kernel information. For details, see the following. This article aims to introduce a priceless resource, Larry Wall's patch program, to Linux beginners. Patch is an interface for finding differences between files using the GNU diff command. diff has many options, but this command is most commonly used to generate a file, this file lists the rows in which the content has changed. It displays two original files, modified rows, and rows ignored because the content has not changed. Patch is typically used to update the source code files in a directory to a new version, thus avoiding the need to download the entire new source code file. To download an effective patch, you only need to download the changed code lines.

Patch originated from a decade ago, when network bandwidth restrictions promoted the development of patch. However, like many Unix tools at that time, patch was still widely used until now. In the programmer magazine of Dr. Dobb's trip in February, Larry Wall made some interesting notes on the early patch:

DDJ: By the way, which patch and diff appeared earlier?

LW: For a long time, diff appears early. I think diff appeared about 10 years earlier than patch. In retrospect, I wondered why no one was thinking about using patch earlier?

But I want to know why. This is largely due to psychological factors. When diff was developed, the programmer added an e option. I think it is the reason for this option. This option was later developed as an ed script, so everyone would say to themselves, "well, if I want to use diff automatically, I will use this option. "Therefore, no one has ever compiled a computer program to obtain output in other formats and use these results. Or those who design diff, or those who benefit from using diff format, are too addicted to it, because you can use diff operations on modified content and make it easy to work properly.

In retrospect, this problem is obvious. In all fairness, this is not so much a flash of inspiration for a genius as a reflection of self-confidence. I developed the first version of rn and continued to write patches for it. This is a mess. You cannot force users to use patches because they can do this manually. Therefore, they will omit some work that they think is unnecessary, and they add new modifications to the original program, thus making the program messy. I wrote a patch so that no one could find an excuse to say it was hard.

I don't know if this is the case, but for many years, I have been telling people that patch has a greater impact on computer culture than rn and Perl. Now, the speed of the Internet is greatly improved. It is easier to distribute the entire release version across the world. It seems that only developers need to transmit patches. I have not transferred the Perl patch toolkit for many years. I think that although patch is becoming increasingly important, it is still a way for developers to exchange ideas. However, for that period of time, patch has actually affected the software development method to a considerable extent.

Larry Wall's comments on patch's declining overall importance in the computer industry may be correct, but in the Free Software world, patch is still an essential tool. The ubiquitous patch enables beginners and non-programmers to simply participate in alpha and beta testing of the software, which is very beneficial to the entire computer industry.

I noticed that the idea of writing this article came into being when such a thing appeared cyclically in the Linux Kernel email list. Someone will post an article about every three months asking for the release of the Linux kernel source code to be independent. It is said that this is because some people are only interested in the i386 code and the disk drive of the IDE, they do not want to download files such as Alpha, or iSCSI and a large number of SCSI drivers for each kernel release version. This article is followed by some patient replies (some articles are not patient). Most of the articles are discussing how to use patches to update the kernel source code. Then Linus Torvalds will again declare that they are not interested in the complicated work of cutting the kernel source program into small pieces, but if anyone wishes, they can freely carry out this independent project. No volunteers have appeared until now. I don't want to condemn kernel hackers who don't have the patience to wait, but make life more complicated. I guess using the kernel directly may be more interesting and challenging than checking the distribution of the entire kernel. Downloading the 11 m kernel source package is a very time-consuming task (for those who access the Internet by time, this is very expensive), but the kernel patch is only dozens of kb in size, it will rarely exceed 1 MB. The kernel source program developed in 2.1.99 on my hard disk has been upgraded to version 2.1.119 through patch. I suspect that if I keep upgrading as soon as the kernel develops, then, you may need to download all the release versions.

Use patch

Patch comes with a good help, which lists many options, but 99% of the time can meet our needs as long as two options:

Patch-p1 <[patchfile]

Patch-R <[patchfile] (used to undo a patch)

-The p1 option indicates the number of layers in the directory on the left of the file name in the patchfile. The top-level directories are different on different machines. To use this option, you need to put your patch in the directory to be patched, and then run path-p1 <[patchfile] in this directory. A brief reference from the Linux kernel patch can be implemented as follows:

Diff-u -- recursive -- new-file v2.1.118/linux/mm/swapfile. c linux/mm/swapfile. c --- v2.1.118/linux/mm/swapfile. c Wed Aug 26 11:37:45 1998 ++ linux/mm/swapfile. c Wed Aug 26 16:01:57 1998 @-489,7 + 489,7 @@

Int swap_header_version;

Int lock_map_size = PAGE_SIZE;

Int nr_good_pages = 0;-char tmp_lock_map = 0; + unsigned long tmp_lock_map = 0;

The application from the patch copied using the-p1 switch in this section can effectively reduce the path of the patch positioning; the patch will find the next subdirectory named/mm in the current directory, next we will find swapfile here. c file, and then wait for patching. In this process, the line starting with a break ("-", Translator's note) is replaced by a line starting with a plus sign ("+", Translator's note. A typical patch contains updates to multiple files. Each part is composed of the output results of running the diff-u command on two versions of files.

Patch displays its output results on the screen during operations, but such output is usually rolled too fast to watch. The original patch file name is *. orig. The new patch file will overwrite the initial file name.

Patch issues

The source of patch problems may vary with different versions, and all versions are available on the network. Larry Wall has not done much work in recent years to update patches. This may be because the last version of Larry Wall can run normally in most cases. In recent years, FSF programmers of the GNU project have released new patches. They first revised the problematic patch, but recently I have been using version 2.5 (which is the release version of Debian2.0 ). In the past, my version 2.1 has been running well. The current version of GNU patch can be obtained from the gnu ftp site, but most people only use the version provided in their Linux release.

Let's assume that you have patched the source program file in a directory, but the patch does not work clearly. This may happen occasionally. During the patching process, an error message is displayed with a line number, indicating which file has a problem. Sometimes the error is obvious. For example, if a semicolon is missing, the error can be corrected without much effort. Another possibility is to delete the problematic part from the patch part, but this may work properly or not depending on the file involved.

Another common misplacement is: Suppose you have a kernel source program file that is not packaged with tar, when you browse each sub-directory under/linux/arch/, you will find Sub-directories of various machine architecture structures, such as Alpa and iSCSI. If you are using Intel processor (or Intel series) Like most Linux users, you can decide to delete these directories, which are not required to compile your special kernel, it only occupies the disk space in vain. A new kernel patch is released after a period of time. At this time, it tries to perform the patch operation. When it finds that it cannot find the Alpha or PPC file required for patching, it will pause. Fortunately, patch allows users to participate in these areas. It will ask "Skip this patch? "Answer" y ", the patch can be executed in the correct path. You may need to answer this question many times, so it is a good way to allow unnecessary directories to be retained on the disk.

Tips for patching the kernel

Many Linux users use patches mainly to patch the kernel source program, so there are some tips to use. The simplest way is to patch the kernel using shell scripts, which can be found in the/scripts subdirectory in the kernel source code tree. This convenient and well-written script was compiled by Nick Holloway in 1995. Two years later, Adam Sulmicki added support for multiple compression formats, including *. bz ,*. bz2, compress, gzip, and unformatted text (that is, the unzipped patch ). This script assumes that when you use the new patch version, your kernel source program is in the/usr/src/linux directory. These default values can be overwritten by the command line switch in this format: patch-kernel [sourcedir [patchdir]. If any part of the patch fails, the Kernel Patching process will fail, but if the patch works clearly, it will call find, which will delete the *. orig files left by all patches.

If you want to view the command output, or you want to keep *. orig file until you confirm that the patch source program has been compiled, run the patch directly according to my experience (as described above, the patch is located in the highest directory of the kernel source program) is very reliable. To avoid unzipping the patch, you can use the following technique before using it:

Gzip-cd patchXX.gz | patch-p1

Or

Bzip2-dc patchXX.bz2 | patch-p1

After using patch, you can use the find program to detect rejected files:

Find.-name *. rej

The syntax may be unclear when you use this command for the first time. "." Indicates that "find" should look for the current directory and use the rule to find all subdirectories under the current directory. Remember, there should be a space before and after the dot. The backslash before the wildcard "*" escapes the asterisks to avoid shell obfuscation. The asterisks have other meanings. If find finds any *. rej file, it prints the file name to the screen. If you exit without any output of find, you can determine whether the patch works correctly.

Another task of find is to delete the *. orig file:

Find.-name *. orig-print0 | xargs-0r rm-f

This command is quite troublesome to use. You can use a new shell alias to replace this command. In your ~ The/. bashrc file contains a line similar to the following:

Alias findorig 'Find.-name *. orig-print0 | xargs-0r rm-F'

You can only enter findorig to call the preceding command. If the alias command definition contains spaces, you must use single quotation marks. In order to use a new alias without having to exit and re-log in, you can type it in the command line as shown in ~ /. Bashrc.

Additional content and concluding remarks

At the time of writing this article, I just upgraded my machine from version 2.1 using patch to version 2.5. Both versions are from the current FSF/GNU maintenance personnel. Now I noticed that the default output of Version 2.5 has changed, and the information displayed on the screen is reduced. Larry Wall's "... hmm" is missing when patch detection is used to fix the row number. The output of Version 2.5 only contains information such as "patching file [filename]", but not as much information as shown in earlier versions. It is undeniable that the information is too fast to be read, but the output can be redirected to a file for future use. This change does not affect the functions of the program, but reduces human components. In my opinion "... hmm "information is the same as the comments in the source code. It is very valuable to remind the user program to display the results of the executed work, just as people are breathing, instead of using a bit set with no results. By adding the -- verbose switch to the patch command line, you can restore the original display content. However, I believe that many users will neither notice this option nor enter this option diligently. Another difference between version 2.1 and version 2.5 is that the *. orig backup file cannot be created unless patch provides the-B option.

For those who are not interested in testing and providing test reports for software and kernel "cutting-edge" bug reports, patch is not mandatory, however, most interesting developments in the Linux world usually fall into this category. It is not difficult to obtain the patch usage. Such efforts can be fully rewarded.