Eric Lee / smarc-ti-linux-kernel

Download as
Browse Code ยป

Commit c594a50db4cbe8b839a70fca0cff524d392531ca

Authored by Randy Dunlap
Committed by Linus Torvalds
1 parent a6d3fe77da
Exists in master and in 20 other branches dlt-processor-sdk-linux-03.00.00.04, newt-ti-linux-3.12.y, processor-sdk-linux-01.00.00, processor-sdk-linux-02.00.01, smarc-ti-linux-3.12.10, smarc-ti-linux-3.12.y, smarc-ti-linux-3.14.y, smarc-ti-linux-3.15.y, smarc-ti-lsk-linux-4.1.y, smarct3x-processor-sdk-04.01.00.06, smarct3x-processor-sdk-linux-02.00.01, smarct3x-processor-sdk-linux-03.00.00.04, smarct4x-800-processor-sdk-linux-02.00.01, smarct4x-processor-sdk-04.01.00.06, smarct4x-processor-sdk-linux-02.00.01, smarct4x-processor-sdk-linux-03.00.00.04, ti-linux-3.12.y, ti-linux-3.14.y, ti-linux-3.15.y, ti-lsk-linux-4.1.y

[PATCH] Docs update: typos, corrections and additions to applying-patches.txt 

Typos/corrections.

A few extra additions on top of Randy's fixes.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Showing 1 changed file with 32 additions and 24 deletions Side-by-side Diff

Documentation/applying-patches.txt
Diff comments   View file @ c594a50
... ... @@ -3,10 +3,9 @@
3 3 ------------------------------------
4 4  
5 5 Original by: Jesper Juhl, August 2005
6   - Last update: 2005-12-02
  6 + Last update: 2006-01-05
7 7  
8 8  
9   -
10 9 A frequently asked question on the Linux Kernel Mailing List is how to apply
11 10 a patch to the kernel or, more specifically, what base kernel a patch for
12 11 one of the many trees/branches should be applied to. Hopefully this document
... ... @@ -77,7 +76,7 @@
77 76  
78 77 If you wish to uncompress the patch file by hand first before applying it
79 78 (what I assume you've done in the examples below), then you simply run
80   -gunzip or bunzip2 on the file - like this:
  79 +gunzip or bunzip2 on the file -- like this:
81 80 gunzip patch-x.y.z.gz
82 81 bunzip2 patch-x.y.z.bz2
83 82  
... ... @@ -95,7 +94,7 @@
95 94 ---
96 95 When patch applies a patch file it attempts to verify the sanity of the
97 96 file in different ways.
98   -Checking that the file looks like a valid patch file, checking the code
  97 +Checking that the file looks like a valid patch file & checking the code
99 98 around the bits being modified matches the context provided in the patch are
100 99 just two of the basic sanity checks patch does.
101 100  
... ... @@ -122,7 +121,7 @@
122 121 read this file to see exactly what change couldn't be applied, so you can
123 122 go fix it up by hand if you wish.
124 123  
125   -If you don't have any third party patches applied to your kernel source, but
  124 +If you don't have any third-party patches applied to your kernel source, but
126 125 only patches from kernel.org and you apply the patches in the correct order,
127 126 and have made no modifications yourself to the source files, then you should
128 127 never see a fuzz or reject message from patch. If you do see such messages
... ... @@ -137,7 +136,7 @@
137 136 find a file to be patched. Most likely you forgot to specify -p1 or you are
138 137 in the wrong directory. Less often, you'll find patches that need to be
139 138 applied with -p0 instead of -p1 (reading the patch file should reveal if
140   -this is the case - if so, then this is an error by the person who created
  139 +this is the case -- if so, then this is an error by the person who created
141 140 the patch but is not fatal).
142 141  
143 142 If you get "Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines)." or a
144 143  
... ... @@ -168,13 +167,17 @@
168 167  
169 168 A message similar to "patch: **** unexpected end of file in patch" or "patch
170 169 unexpectedly ends in middle of line" means that patch could make no sense of
171   -the file you fed to it. Either your download is broken or you tried to feed
172   -patch a compressed patch file without uncompressing it first.
  170 +the file you fed to it. Either your download is broken, you tried to feed
  171 +patch a compressed patch file without uncompressing it first, or the patch
  172 +file that you are using has been mangled by a mail client or mail transfer
  173 +agent along the way somewhere, e.g., by splitting a long line into two lines.
  174 +Often these warnings can easily be fixed by joining (concatenating) the
  175 +two lines that had been split.
173 176  
174 177 As I already mentioned above, these errors should never happen if you apply
175 178 a patch from kernel.org to the correct version of an unmodified source tree.
176 179 So if you get these errors with kernel.org patches then you should probably
177   -assume that either your patch file or your tree is broken and I'd advice you
  180 +assume that either your patch file or your tree is broken and I'd advise you
178 181 to start over with a fresh download of a full kernel tree and the patch you
179 182 wish to apply.
180 183  
... ... @@ -200,10 +203,10 @@
200 203 Another alternative is `ketchup', which is a python script for automatic
201 204 downloading and applying of patches (http://www.selenic.com/ketchup/).
202 205  
203   - Other nice tools are diffstat which shows a summary of changes made by a
204   -patch, lsdiff which displays a short listing of affected files in a patch
205   -file, along with (optionally) the line numbers of the start of each patch
206   -and grepdiff which displays a list of the files modified by a patch where
  206 + Other nice tools are diffstat, which shows a summary of changes made by a
  207 +patch; lsdiff, which displays a short listing of affected files in a patch
  208 +file, along with (optionally) the line numbers of the start of each patch;
  209 +and grepdiff, which displays a list of the files modified by a patch where
207 210 the patch contains a given regular expression.
208 211  
209 212  
... ... @@ -228,8 +231,8 @@
228 231 In place of ftp.kernel.org you can use ftp.cc.kernel.org, where cc is a
229 232 country code. This way you'll be downloading from a mirror site that's most
230 233 likely geographically closer to you, resulting in faster downloads for you,
231   -less bandwidth used globally and less load on the main kernel.org servers -
232   -these are good things, do use mirrors when possible.
  234 +less bandwidth used globally and less load on the main kernel.org servers --
  235 +these are good things, so do use mirrors when possible.
233 236  
234 237  
235 238 The 2.6.x kernels
236 239  
237 240  
... ... @@ -237,14 +240,14 @@
237 240 These are the base stable releases released by Linus. The highest numbered
238 241 release is the most recent.
239 242  
240   -If regressions or other serious flaws are found then a -stable fix patch
  243 +If regressions or other serious flaws are found, then a -stable fix patch
241 244 will be released (see below) on top of this base. Once a new 2.6.x base
242 245 kernel is released, a patch is made available that is a delta between the
243 246 previous 2.6.x kernel and the new one.
244 247  
245   -To apply a patch moving from 2.6.11 to 2.6.12 you'd do the following (note
  248 +To apply a patch moving from 2.6.11 to 2.6.12, you'd do the following (note
246 249 that such patches do *NOT* apply on top of 2.6.x.y kernels but on top of the
247   -base 2.6.x kernel - if you need to move from 2.6.x.y to 2.6.x+1 you need to
  250 +base 2.6.x kernel -- if you need to move from 2.6.x.y to 2.6.x+1 you need to
248 251 first revert the 2.6.x.y patch).
249 252  
250 253 Here are some examples:
... ... @@ -266,7 +269,7 @@
266 269  
267 270 The 2.6.x.y kernels
268 271 ---
269   - Kernels with 4 digit versions are -stable kernels. They contain small(ish)
  272 + Kernels with 4-digit versions are -stable kernels. They contain small(ish)
270 273 critical fixes for security problems or significant regressions discovered
271 274 in a given 2.6.x kernel.
272 275  
273 276  
... ... @@ -277,9 +280,14 @@
277 280 If no 2.6.x.y kernel is available, then the highest numbered 2.6.x kernel is
278 281 the current stable kernel.
279 282  
  283 + note: the -stable team usually do make incremental patches available as well
  284 + as patches against the latest mainline release, but I only cover the
  285 + non-incremental ones below. The incremental ones can be found at
  286 + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/incr/
  287 +
280 288 These patches are not incremental, meaning that for example the 2.6.12.3
281 289 patch does not apply on top of the 2.6.12.2 kernel source, but rather on top
282   -of the base 2.6.12 kernel source.
  290 +of the base 2.6.12 kernel source .
283 291 So, in order to apply the 2.6.12.3 patch to your existing 2.6.12.2 kernel
284 292 source you have to first back out the 2.6.12.2 patch (so you are left with a
285 293 base 2.6.12 kernel source) and then apply the new 2.6.12.3 patch.
286 294  
... ... @@ -345,12 +353,12 @@
345 353 repository, hence the name).
346 354  
347 355 These patches are usually released daily and represent the current state of
348   -Linus' tree. They are more experimental than -rc kernels since they are
  356 +Linus's tree. They are more experimental than -rc kernels since they are
349 357 generated automatically without even a cursory glance to see if they are
350 358 sane.
351 359  
352 360 -git patches are not incremental and apply either to a base 2.6.x kernel or
353   -a base 2.6.x-rc kernel - you can see which from their name.
  361 +a base 2.6.x-rc kernel -- you can see which from their name.
354 362 A patch named 2.6.12-git1 applies to the 2.6.12 kernel source and a patch
355 363 named 2.6.13-rc3-git2 applies to the source of the 2.6.13-rc3 kernel.
356 364  
357 365  
... ... @@ -393,12 +401,12 @@
393 401 ensure maximum testing.
394 402  
395 403 This branch is in constant flux and contains many experimental features, a
396   -lot of debugging patches not appropriate for mainline etc and is the most
  404 +lot of debugging patches not appropriate for mainline etc., and is the most
397 405 experimental of the branches described in this document.
398 406  
399 407 These kernels are not appropriate for use on systems that are supposed to be
400 408 stable and they are more risky to run than any of the other branches (make
401   -sure you have up-to-date backups - that goes for any experimental kernel but
  409 +sure you have up-to-date backups -- that goes for any experimental kernel but
402 410 even more so for -mm kernels).
403 411  
404 412 These kernels in addition to all the other experimental patches they contain