2.1.1. Diff and Patch 19
wars
3
with free software developers, email and patches are still considered the only
method for generating discussion on code changes. In fact, some patches will not be
considered for acceptance unless there is first some discussion on the main mailing
list. In open source software, code quality is considered to be directly related to the
amount of peer review. As a number of CVS and plain patch portals are available to
the BitKeeper tree and patches are still the preferred means of discussion, it means
that at no point is a developer required to have BitKeeper to make contributions to
the kernel but the tool is still something that developers should be aware of.
2.1.1 Diff and Patch
The two tools for creating and applying patches are diff and patch, both of which
are GNU utilities available from the GNU website
4
. diff is used to generate patches
and patch is used to apply them. While the tools have numerous options, there is
a “preferred usage”.
Patches generated with diff should always be unified diff and generated from
one directory above the kernel source root. A unified diff includes more information
that just the differences between two lines. It begins with a two line header with
the names and creation dates of the two files that diff is comparing. After that,
the “diff” will consist of one or more “hunks”. The beginning of each hunk is marked
with a line beginning with @@ which includes the starting line in the source code and
how many lines there are before and after the hunk is applied. The hunk includes
“context” lines which show lines above and below the changes to aid a human reader.
Each line begins with a +, - or blank. If the mark is +, the line is added. If a -, the
line is removed and a blank is to leave the line alone as it is there just to provide
context. The reasoning behind generating from one directory above the kernel root
is that it is easy to see quickly which version the patch has been applied against and
it makes the scripting of applying patches easier if each patch is generated the same
way.
Let us take for example, a very simple change has been made to mm/page_alloc.c
which adds a small piece of commentary. The patch is generated as follows. Note
that this command should be all on one line minus the backslashes.
mel@joshua: kernels/ $ diff -u \
linux-2.4.20-clean/mm/page_alloc.c \
linux-2.4.20-mel/mm/page_alloc.c > example.patch
This generates a unified context diff (-u switch) between the two files and places
the patch in example.patch as shown in Figure 2.1.1.
From this patch, it is clear even at a casual glance which files are affected
(page_alloc.c), which line it starts at (76) and that the block was 8 lines be-
fore the changes and 23 after them. The new lines are clearly marked with a +.
3
A regular feature of kernel discussions meaning an acrimonious argument often containing
insults bordering on the personal type.
4
http://www.gnu.org
我的内容管理
展开
