雜記

下載來源: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.1.18.tar.gz

以下翻譯於 Documentation/applying-patches.txt中的關於patch內容 

 若有錯誤請指正..感謝

What is a patch?
---
A patch is a small text document containing a delta of changes between two
different versions of a source tree. Patches are created with the `diff'
program.
To correctly apply a patch you need to know what base it was generated from
and what new version the patch will change the source tree into. These
should both be present in the patch file metadata or be possible to deduce
from the filename.
patch是一個小文字檔案, 它包含了一個source tree之兩個不同版本之間的變動之差量(delta)
patch是diff程序所創造出來
為了正確地提供一個Patch, 你必須知道它應該要從什麼基礎而被獲得, 以及此patch將改變source tree去成為什麼新的版本.
那些應該都要存在在patch檔案元數據(metadata)裡, 並且可能去從檔名推斷

How do I apply or revert a patch?
我要如何去應用或復原一個patch?
---
You apply a patch with the `patch' program. The patch program reads a diff
(or patch) file and makes the changes to the source tree described in it.
patch功能讀取一個diff(或patch)檔案, 並且產出對於source tree之所有變動描述在裡面

Patches for the Linux kernel are generated relative to the parent directory
holding the kernel source dir.
被產生出之Linux kernel之Patchs, 是關係於 kernel source資料夾之父目錄

This means that paths to files inside the patch file contain the name of the
kernel source directories it was generated against (or some other directory
names like "a/" and "b/").
這代表著, 那些patch檔案裡面的路徑, 也會包含了被用來獲得patch之kernel source資料夾的名稱
(或者一些其他目錄取名為類似"a/"和"b/")

Since this is unlikely to match the name of the kernel source dir on your
local machine (but is often useful info to see what version an otherwise
unlabeled patch was generated against) you should change into your kernel
source directory and then strip the first element of the path from filenames
in the patch file when applying it (the -p1 argument to `patch' does this).
既然這並不太可能去匹配於在妳的本機上的kernel source資料夾的名稱(當然它常常對去查看是很有用的資訊)
你應該進入你的kernel source資料夾裡面去並且接著除去在pahtch檔案裡面從檔名之路徑的第一個元素資料夾(patch的-p1參數就是在做這件事)

為了還原前面一個被apply的patch, 請使用-R 參數去patch.
所以如果你應用了一個像這樣的Patch:
To revert a previously applied patch, use the -R argument to patch.
So, if you applied a patch like this:
patch -p1 < ../patch-x.y.z
妳可以還原它像這樣:
You can revert (undo) it like this:
patch -R -p1 < ../patch-x.y.z

How do I feed a patch/diff file to `patch'?
我要如何為patch提供一個patch/diff
---
這個(如同一般Linux及其他UNIX類似之操作系統)可以在幾個不同的方式被完成
This (as usual with Linux and other UNIX like operating systems) can be
done in several different ways.
在所有下列的例子裡, 我提供patch的檔案, 是經由使用下列語法之標準輸入(stdin):
In all the examples below I feed the file (in uncompressed form) to patch
via stdin using the following syntax:
patch -p1 < path/to/patch-x.y.z

如果你只想要可以去遵照下面的例子, 並且並不想去知道關於更多不只一種去使用patch的方式
那麼你可以停止閱讀目前這個章節
If you just want to be able to follow the examples below and don't want to
know of more than one way to use patch, then you can stop reading this
section here.

patch也可以經由-i參數去獲得檔案名稱, 就像這樣:
Patch can also get the name of the file to use via the -i argument, like
this:
patch -p1 -i path/to/patch-x.y.z

如果你的patch檔案被經由gzip或bzip2壓縮, 而且你不想在apply它之前去解壓,
那麼你可以提供它去patch如以下:
If your patch file is compressed with gzip or bzip2 and you don't want to
uncompress it before applying it, then you can feed it to patch like this
instead:
zcat path/to/patch-x.y.z.gz | patch -p1
bzcat path/to/patch-x.y.z.bz2 | patch -p1

如果你希望在apply它之前去經由手動解壓patch檔案(在這裡我是假設你已經完成了下面的範例)
那麼你可簡單執行gunzip或bunzip2, 如以下:
If you wish to uncompress the patch file by hand first before applying it
(what I assume you've done in the examples below), then you simply run
gunzip or bunzip2 on the file -- like this:
gunzip patch-x.y.z.gz
bunzip2 patch-x.y.z.bz2

它們會留一個完整的patch-x.y.z檔案, 你可以經由標準輸入(stdin)或-i參數去提供給patch
Which will leave you with a plain text patch-x.y.z file that you can feed to
patch via stdin or the -i argument, as you prefer.

對於patch其他好用的參數...(略)
A few other nice arguments for patch are -s which causes patch to be silent
except for errors which is nice to prevent errors from scrolling out of the
screen too fast, and --dry-run which causes patch to just print a listing of
what would happen, but doesn't actually make any changes. Finally --verbose
tells patch to print more information about the work being done.

patch時的常見錯誤
Common errors when patching
---
當patch程式 apply一個Patch檔案, 它會用各種不同方式去嘗試去校驗檔案的健全
When patch applies a patch file it attempts to verify the sanity of the
file in different ways.
檢查那些檔案看起來是否為合法檔案, 且確認被維護之那附近的code是否皆匹配於在patch裡被提供的內容
這兩個方式為唯二基本的健全檢查
Checking that the file looks like a valid patch file and checking the code
around the bits being modified matches the context provided in the patch are
just two of the basic sanity checks patch does.

如果patch遭遇到一些看起來並不正確的困難, 有兩個方法.
它可以拒絕apply變更並且中止, 或者是可以去嘗試找到一個方式去使得patch以較少變動去apply.
If patch encounters something that doesn't look quite right it has two
options. It can either refuse to apply the changes and abort or it can try
to find a way to make the patch apply with a few minor changes.

有一個例子. 有些東西"並不是真的那麼正確"那麼patch將會嘗試去安排是否全部內容都匹配,
被改變的行數都匹配, 但那些行數的數字是不同的.
這是可能發生的, 舉例, 如果patch造成了一個在檔案中間內容的更改, 但是因為一些理由
在檔案開頭的附近的少許行數已經被增加或移除
在這樣的狀況裡, 全部看起來都很好
它只往上移或下移一點, 並且patch將會如常調整行數並且apply這個Patch
One example of something that's not 'quite right' that patch will attempt to
fix up is if all the context matches, the lines being changed match, but the
line numbers are different. This can happen, for example, if the patch makes
a change in the middle of the file but for some reasons a few lines have
been added or removed near the beginning of the file. In that case
everything looks good it has just moved up or down a bit, and patch will
usually adjust the line numbers and apply the patch.

每當apply了一個patch, 它都必須去做一點維護去使它契合
它將會經由表明說patch中有用'fuzz'去做apply, 以告知你
你應該要對於那些變更感到警惕
因為即使patch有可能使它正確, 並非總是會正確, 而且結果有時候會是錯的
Whenever patch applies a patch that it had to modify a bit to make it fit
it'll tell you about it by saying the patch applied with 'fuzz'.
You should be wary of such changes since even though patch probably got it
right it doesn't /always/ get it right, and the result will sometimes be
wrong.

當patch遭遇到一個變更(change), 那麼它即無法用fuzz安排, 他會拒絕並且留下一個.rej檔案
你可以讀取這個檔案, 去實際看看哪個變更無法被apply, 如此一來你便可以去用手動安排(如果你想的話)
When patch encounters a change that it can't fix up with fuzz it rejects it
outright and leaves a file with a .rej extension (a reject file). You can
read this file to see exactly what change couldn't be applied, so you can
go fix it up by hand if you wish.

如果你並沒有任何third-party patchs檔案可去apply你的kernel source,
只是從kernel.org獲得的Patchs檔案, 且你以正確的指令去apply那些patch檔案
並且並沒有自行維護那些source files, 那麼你在patch時應該不會看到任何fuzz或reject訊息.
如果你有看到這類訊息, 那麼有很高的機率可能那是你本機端的source tree或者patch檔案是損毀的.
在這樣的狀況下, 你應該要去嘗試重新下載patch, 如果那些東西還不ok那建議你應該
去完全重新從kernel.org下載
If you don't have any third-party patches applied to your kernel source, but
only patches from kernel.org and you apply the patches in the correct order,
and have made no modifications yourself to the source files, then you should
never see a fuzz or reject message from patch. If you do see such messages
anyway, then there's a high risk that either your local source tree or the
patch file is corrupted in some way. In that case you should probably try
re-downloading the patch and if things are still not OK then you'd be advised
to start with a fresh tree downloaded in full from kernel.org.

接著看更多一點patch可以製造出的訊息
Let's look a bit more at some of the messages patch can produce.

如果patch停止並且出現"File to patch:"提示, 那麼patch即無法找到檔案去patch
最有可能是, 你忘記去標明-p1 或者你正在錯誤的資料夾裡面.
其餘少見的可能狀況就是, 你將會發現需要用帶著-p0而非-p1之apply去patch檔案
(讀取patch file應該會揭露是否為這個狀況, 如果是的話, 那麼這就是一個經由那個產生patch的人所造成的錯誤, 並非本來就會發生)
If patch stops and presents a "File to patch:" prompt, then patch could not
find a file to be patched. Most likely you forgot to specify -p1 or you are
in the wrong directory. Less often, you'll find patches that need to be
applied with -p0 instead of -p1 (reading the patch file should reveal if
this is the case -- if so, then this is an error by the person who created
the patch but is not fatal).

如果你得到"Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines)."或者一個長得類似的訊息
那麼就代表著patch必須去調整變更的位置(在這個範例中, 它必須從那個它預期去變更的地方去移動7行去使變更契合)
因為檔案跟預期不同的原因, 結果檔案可能或可能不會OK.
如果你嘗試去apply一個由不同kernel版本產生的patch檔, 這會經常發生
If you get "Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines)." or a
message similar to that, then it means that patch had to adjust the location
of the change (in this example it needed to move 7 lines from where it
expected to make the change to make it fit).
The resulting file may or may not be OK, depending on the reason the file
was different than expected.
This often happens if you try to apply a patch that was generated against a
different kernel version than the one you are trying to patch.

如果你得到一個類似"Hunk #3 FAILED at 2387."的訊息, 那麼它代表著
patch 可能無法被正確地apply, 並且patch程式沒有能力去fuzz.
這將會生成一個.rej檔案, 此檔案有著造成Patch失敗的變更,
並且也會有一個.orig檔案顯示你原本的無法被變更的內容.
If you get a message like "Hunk #3 FAILED at 2387.", then it means that the
patch could not be applied correctly and the patch program was unable to
fuzz its way through. This will generate a .rej file with the change that
caused the patch to fail and also a .orig file showing you the original
content that couldn't be changed.

如果你得到"Reversed (or previously applied) patch detected! Assume -R? [n]"的訊息
那麼patch偵測到在patch裡的變更似乎已經被製作過了
如果你實際上以前已經apply這個patch, 而且你只是不小心重複apply它
那麼你只需要選[n]並且中斷這個patch.
如果你以前apply這個patch並且實際上打算去還原(revert)它, 但是卻忘了去標註-R
那麼你可以選[y]去使得patch去還原它
如果patch的創作者在創造patch時, 還原了source以及目標資料夾, 那這也會發生
並且在那樣的狀況裡, 還原patch這個動作, 將會實際上去apply它(蛤?)
If you get "Reversed (or previously applied) patch detected! Assume -R? [n]"
then patch detected that the change contained in the patch seems to have
already been made.
If you actually did apply this patch previously and you just re-applied it
in error, then just say [n]o and abort this patch. If you applied this patch
previously and actually intended to revert it, but forgot to specify -R,
then you can say [y]es here to make patch revert it for you.
This can also happen if the creator of the patch reversed the source and
destination directories when creating the patch, and in that case reverting
the patch will in fact apply it.

一個類似"patch: **** unexpected end of file in patch"或"patch
unexpectedly ends in middle of line"的訊息代表著, patch可能判斷你提供給它的檔案沒有意義.
有可能是你的下載損毀, 或者可能是你正在使用的patch檔已經經由mail客戶端或mail傳送錯..(略)
A message similar to "patch: **** unexpected end of file in patch" or "patch
unexpectedly ends in middle of line" means that patch could make no sense of
the file you fed to it. Either your download is broken, you tried to feed
patch a compressed patch file without uncompressing it first, or the patch
file that you are using has been mangled by a mail client or mail transfer
agent along the way somewhere, e.g., by splitting a long line into two lines.
Often these warnings can easily be fixed by joining (concatenating) the
two lines that had been split.