📄 00000064.htm
字号:
they should feel free to do so as an independent project. So
<BR>far no-one has volunteered. I can't blame the kernel-hackers for not wanting <BR>to further complicate their lives; I imagine it would be
<BR>much more interesting and challenging to work directly with the kernel than <BR>to overhaul the entire kernel distribution scheme!
<BR>Downloading an eleven megabyte kernel source archive is time-consuming (and, <BR>for those folks paying by the minute for net
<BR>access, expensive as well) but the kernel patches can be as small as a few <BR>dozen kilobytes, and are hardly ever larger than one
<BR>megabyte. The 2.1.119 development kernel source on my hard disk has been <BR>incrementally patched up from version 2.1.99, and I
<BR>doubt if I'd follow the development as closely if I had to download each <BR>release in its entirety.
<BR>
<BR> Using Patch
<BR>
<BR>Patch comes with a good manual-page which lists its numerous options, but 99% <BR>of the time just two of them will suffice:
<BR>
<BR> patch -p1 < [patchfile]
<BR> patch -R < [patchfile] (used to undo a patch)
<BR>
<BR>The -p1 option strips the left-most directory level from the filenames in the <BR>patch-file, as the top-level directory is likely to vary on
<BR>different machines. To use this option, place your patch within the directory <BR>being patched, and then run patch -p1 < [patchfile]
<BR>from within that directory. A short excerpt from a Linux kernel patch will <BR>illustrate this:
<BR>
<BR>
<BR>diff -u --recursive --new-file v2.1.118/linux/mm/swapfile.c linux/mm/swapfile. <BR>c
<BR>--- v2.1.118/linux/mm/swapfile.c Wed Aug 26 11:37:45 1998
<BR>+++ linux/mm/swapfile.c Wed Aug 26 16:01:57 1998
<BR>@@ -489,7 +489,7 @@
<BR> int swap_header_version;
<BR> int lock_map_size = PAGE_SIZE;
<BR> int nr_good_pages = 0;
<BR>- char tmp_lock_map = 0;
<BR>+ unsigned long tmp_lock_map = 0;
<BR>
<BR>Applying the patch from which this segment was copied with the -p1 switch <BR>effectively truncates the path which patch will seek;
<BR>patch will look for a subdirectory of the current directory named /mm, and <BR>should then find the swapfile.c file there, waiting to be
<BR>patched. In this excerpt, the line preceded by a dash will be replaced with <BR>the line preceded by a plus sign. A typical patch will
<BR>contain updates for many files, each section consisting of the output of diff <BR>-u run on two versions of a file.
<BR>
<BR>Patch displays its output to the screen as it works, but this output usually <BR>scrolls by too quickly to read. The original, pre-patch files
<BR>are renamed *.orig, while the new patched files will bear the original <BR>filenames.
<BR>
<BR> Patching Problems
<BR>
<BR>One possible source of problems using patch is differences between various <BR>versions, all of which are available on the net. Larry
<BR>Wall hasn't done much to improve patch in recent years, possibly because his <BR>last release of the utility works well in the majority
<BR>of situations. FSF programmers from the GNU project have been releasing new <BR>versions of patch for the past several years. Their
<BR>first revisions of patch had a few problems, but I've been using version 2.5 <BR>(which is the version distributed with Debian 2.0) lately
<BR>with no problems. Version 2.1 has worked well for me in the past. The source <BR>for the current GNU version of patch is available
<BR>from the GNU FTP site, though most people will just use the version supplied <BR>with their distribution of Linux.
<BR>
<BR>Let's say you have patched a directory of source files, and the patch didn't <BR>apply cleanly . This happens occasionally, and when it
<BR>does patch will show an error message indicating which file confused it, <BR>along with the line numbers. Sometimes the error will be
<BR>obvious, such as an omitted semicolon, and can be fixed without too much <BR>trouble. Another possibility is to delete from the patch
<BR>the section which is causing trouble, but this may or may not work, depending <BR>on the file involved.
<BR>
<BR>Another common error scenario: suppose you have un-tarred a kernel source <BR>archive, and while exploring the various
<BR>subdirectories under /linux/arch/ you notice the various machine architecture <BR>subdirectories, such as alpha, sparc, etc.
<BR>If you, like most Linux users, are running a machine with an Intel processor <BR>(or one of the Intel clones), you might decide to delete
<BR>these directories, which are not needed for compiling your particular kernel <BR>and which occupy needed disk space. Some time later
<BR>a new kernel patch is released and while attempting to apply it patch stalls <BR>when it is unable to find the Alpha or PPC files it
<BR>would like to patch. Luckily patch allows user intervention at this point, <BR>asking the question "Skip this patch?" Tell it "y", and patch
<BR>will proceed along its merry way. You will probably have to answer the <BR>question numerous times, which is a good argument for
<BR>allowing the un-needed directories to remain on your disk.
<BR>
<BR> Kernel-Patching Tips
<BR>
<BR>Many Linux users use patch mainly for patching the kernel source, so a few <BR>tips are in order. Probably the easiest method is to
<BR>use the shell-script patch-kernel, which can be found in the /scripts <BR>subdirectory of the kernel source-tree. This handy and
<BR>well-written script was written by Nick Holloway in 1995; a couple of years <BR>later Adam Sulmicki added support for several
<BR>compression algorithms, including *.bz, *.bz2, compress, gzip, and plain-text <BR>(i.e., a patch which has already been uncompressed).
<BR>The script assumes that your kernel source is in /usr/src/linux,, with your <BR>new patch located in the current directory.
<BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -