Lines Matching refs:to
9 A frequently asked question on the Linux Kernel Mailing List is how to apply
10 a patch to the kernel or, more specifically, what base kernel a patch for
11 one of the many trees/branches should be applied to. Hopefully this document
12 will explain this to you.
14 In addition to explaining how to apply and revert patches, a brief
15 description of the different kernel trees (and examples of how to apply
24 To correctly apply a patch you need to know what base it was generated from
26 should both be present in the patch file metadata or be possible to deduce
33 (or patch) file and makes the changes to the source tree described in it.
35 Patches for the Linux kernel are generated relative to the parent directory
38 This means that paths to files inside the patch file contain the name of the
41 Since this is unlikely to match the name of the kernel source dir on your
42 local machine (but is often useful info to see what version an otherwise
45 in the patch file when applying it (the -p1 argument to `patch' does this).
47 To revert a previously applied patch, use the -R argument to patch.
55 How do I feed a patch/diff file to `patch'?
59 In all the examples below I feed the file (in uncompressed form) to patch
61 patch -p1 < path/to/patch-x.y.z
63 If you just want to be able to follow the examples below and don't want to
64 know of more than one way to use patch, then you can stop reading this
67 Patch can also get the name of the file to use via the -i argument, like
69 patch -p1 -i path/to/patch-x.y.z
71 If your patch file is compressed with gzip or bzip2 and you don't want to
72 uncompress it before applying it, then you can feed it to patch like this
74 zcat path/to/patch-x.y.z.gz | patch -p1
75 bzcat path/to/patch-x.y.z.bz2 | patch -p1
77 If you wish to uncompress the patch file by hand first before applying it
83 Which will leave you with a plain text patch-x.y.z file that you can feed to
86 A few other nice arguments for patch are -s which causes patch to be silent
87 except for errors which is nice to prevent errors from scrolling out of the
88 screen too fast, and --dry-run which causes patch to just print a listing of
90 tells patch to print more information about the work being done.
95 When patch applies a patch file it attempts to verify the sanity of the
102 options. It can either refuse to apply the changes and abort or it can try
103 to find a way to make the patch apply with a few minor changes.
105 One example of something that's not 'quite right' that patch will attempt to
113 Whenever patch applies a patch that it had to modify a bit to make it fit
121 read this file to see exactly what change couldn't be applied, so you can
124 If you don't have any third-party patches applied to your kernel source, but
126 and have made no modifications yourself to the source files, then you should
131 to start with a fresh tree downloaded in full from kernel.org.
135 If patch stops and presents a "File to patch:" prompt, then patch could not
136 find a file to be patched. Most likely you forgot to specify -p1 or you are
137 in the wrong directory. Less often, you'll find patches that need to be
143 message similar to that, then it means that patch had to adjust the location
144 of the change (in this example it needed to move 7 lines from where it
145 expected to make the change to make it fit).
148 This often happens if you try to apply a patch that was generated against a
149 different kernel version than the one you are trying to patch.
152 patch could not be applied correctly and the patch program was unable to
154 caused the patch to fail and also a .orig file showing you the original
158 then patch detected that the change contained in the patch seems to have
162 previously and actually intended to revert it, but forgot to specify -R,
163 then you can say [y]es here to make patch revert it for you.
168 A message similar to "patch: **** unexpected end of file in patch" or "patch
170 the file you fed to it. Either your download is broken, you tried to feed
178 a patch from kernel.org to the correct version of an unmodified source tree.
181 to start over with a fresh download of a full kernel tree and the patch you
182 wish to apply.
185 Are there any alternatives to `patch'?
189 You can use the `interdiff' program (http://cyberelk.net/tim/patchutils/) to
192 This will let you move from something like 2.6.12.2 to 2.6.12.3 in a single
193 step. The -z flag to interdiff will even let you feed it patches in gzip or
197 Here's how you'd go from 2.6.12.2 to 2.6.12.3 in a single step:
200 Although interdiff may save you a step or two you are generally advised to
233 likely geographically closer to you, resulting in faster downloads for you,
248 To apply a patch moving from 2.6.11 to 2.6.12, you'd do the following (note
250 base 2.6.x kernel -- if you need to move from 2.6.x.y to 2.6.x+1 you need to
255 # moving from 2.6.11 to 2.6.12
256 $ cd ~/linux-2.6.11 # change to kernel source dir
261 # moving from 2.6.11.1 to 2.6.12
262 $ cd ~/linux-2.6.11.1 # change to kernel source dir
291 So, in order to apply the 2.6.12.3 patch to your existing 2.6.12.2 kernel
292 source you have to first back out the 2.6.12.2 patch (so you are left with a
308 tool) tree to be in a reasonably sane state adequate for testing.
311 you intend to run them. This is however the most stable of the main
316 This is a good branch to run for people who want to help out testing
317 development kernels but do not want to run some of the really experimental
320 The -rc patches are not incremental, they apply to a base 2.6.x kernel, just
327 Here are 3 examples of how to apply these patches:
329 # first an example of moving from 2.6.12 to 2.6.13-rc3
335 # now let's move from 2.6.13-rc3 to 2.6.13-rc5
342 # finally let's try and move from 2.6.12.3 to 2.6.13-rc5
343 $ cd ~/linux-2.6.12.3 # change to the kernel source dir
357 generated automatically without even a cursory glance to see if they are
360 -git patches are not incremental and apply either to a base 2.6.x kernel or
362 A patch named 2.6.12-git1 applies to the 2.6.12 kernel source and a patch
363 named 2.6.13-rc3-git2 applies to the source of the 2.6.13-rc3 kernel.
365 Here are some examples of how to apply these patches:
367 # moving from 2.6.12 to 2.6.12-git1
368 $ cd ~/linux-2.6.12 # change to the kernel source dir
373 # moving from 2.6.12-git1 to 2.6.13-rc2-git3
374 $ cd ~/linux-2.6.12-git1 # change to the kernel source dir
391 Once a patch has proved its worth in -mm for a while Andrew pushes it on to
394 Although it's encouraged that patches flow to Linus via the -mm tree, this
397 to Linus, even though (or after) they have been merged and tested in -mm (or
400 You should generally strive to get your patches into mainline via -mm to
407 These kernels are not appropriate for use on systems that are supposed to be
408 stable and they are more risky to run than any of the other branches (make
409 sure you have up-to-date backups -- that goes for any experimental kernel but
412 These kernels in addition to all the other experimental patches they contain
417 tree is to weed out regressions, crashes, data corruption bugs, build
424 kernels are released in between each -rc kernel (1 to 3 is common).
425 The -mm kernels apply to either a base 2.6.x kernel (when no -rc kernels
426 have been released yet) or to a Linus -rc kernel.
430 # moving from 2.6.12 to 2.6.12-mm1
431 $ cd ~/linux-2.6.12 # change to the 2.6.12 source dir
436 # moving from 2.6.12-mm1 to 2.6.13-rc3-mm3
448 I hope you are now clear on how to apply the various patches and help testing
451 Thank you's to Randy Dunlap, Rolf Eike Beer, Linus Torvalds, Bodo Eggert,
453 forgotten for their reviews and contributions to this document.