This is the way Trond showed us to maintain patches against the linux kernel. It's simple to use and seems to work well.
Start with a plain vanilla kernel source directory,
me@mybox$ cd ~/my_linux_trees/ me@mybox$ wget http://www.kernel.org/pub/linux/kernel/v2.5/linux-2.5.55.tar.gz me@mybox$ tar -xzvf linux-2.5.55.tar.gz
and then create a new directory to work in and populate it with symlinks to linux-2.5.55 using lndir:
me@mybox$ mkdir linux-2.5.55-foo/ me@mybox$ cd linux-2.5.55-foo/ me@mybox$ lndir -silent ../linux-2.5.55 me@mybox$ cd ..; ls linux-2.5.55 linux-2.5.55-foo linux-2.5.55.tar.gz
Now say you want to edit fs/nfs/inode.c. Currently linux-2.5.55-foo/fs/inode.c is just a symlink to linux-2.5.55/fs/inode.c; first you want to replace it with a copy of itself. The provided "delink" script does this for you:
me@mybox$ cd linux-2.5.55-foo/fs/nfs/ me@mybox$ ls -l inode.c lrwxrwxrwx 1 me me 36 Feb 5 12:02 inode.c -> ../../../linux-2.5.55/fs/nfs/inode.c me@mybox$ delink inode.c; ls -l inode.c -rw-r--r-- 1 me me 42424 Feb 5 12:02 inode.c
Now edit inode.c normally. When you're done, you want to distribute a patch against linux-2.5.55 that implements your cool new feature:
me@mybox$ cd ~/my_linux_trees/ me@mybox$ diff -urN linux-2.5.55 linux-2.5.55-foo >linux-2.5.55-foo.diff
Now inspect the resulting diff to make sure it looks reasonable. If you did a "make" in one of those directories while testing your change, you may find that it contains a lot of .o files and other garbage. Oops! Big mistake. Never build a kernel inside one of those source trees. Instead, use lndir to create a build directory and build the kernel there:
me@mybox$ mkdir build-linux-2.5.55-foo me@mybox$ cd build-linux-2.5.55-foo me@mybox$ lndir -silent ../linux-2.5.55-foo me@mybox$ make menuconfig && make bzImage && etc.....
This way you can build as many different kernels you want without disturbing the pristine source trees.
If you later decide to try applying linux-2.5.55-foo.diff to another kernel tree, you can use patch:
me@mybox$ ls linux-2.5.59 linux-2.5.55-foo.diff me@mybox$ mkdir linux-2.5.59-foo me@mybox$ cd linux-2.5.59-foo me@mybox$ patch -p1 <../linux-2.5.59-foo.diff
As a consequence of the way patch works, it will do the right thing with the symlinks: when it modifies a file, it will replace it with a copy first rather than modifying the linked file.
The other two provided tools, make_diffs and apply_patches, automate the tasks of, respectively, making diffs between a series of such trees, and applying a series of patches to a single tree. To use make_diffs:
me@mybox$ make_diffs linux-2.5.55 linux-2.5.55-1 linux-2.5.55-2 ....
this will create a diff between linux 2.5.55 and linux-2.5.55-1, another diff between linux-2.5.55-1 and linux-2.5.55-2, etc. To apply a series of patches:
me@mybox$ apply_patches --source=linux-2.5.55 ~/my_diffs/linux-2.5.55-1.diff ~/my_diffs/linux-2.5.55-2.diff ....
and a bunch of new trees will be created, named after the corresponding patches. Note that the patches must be given by absolute pathnames. This is all made easier if you stick to some naming convention that ensures that the patches and trees all have names which sort in the order they're meant to be applied in. One convention is to name them as in this example:
me@mybox$ ls my_diffs linux-2.5.55-01-auth2.diff linux-2.5.55-06-krb5.diff linux-2.5.55-02-rpc_encode.diff linux-2.5.55-07-rpc_svcgss.diff linux-2.5.55-03-rpc_gss.diff linux-2.5.55-08-rpc_integ.diff linux-2.5.55-04-auth_upcall.diff linux-2.5.55-09-rpc_priv.diff linux-2.5.55-05-auth_upcall2.diff linux-2.5.55-10-idmap.diff
The entire series of patches above can be applied in the correct order just by doing:
me@mybox$ apply_patches --source=linux-2.5.55 ~/my_diffs/*.diff
That's it. Mail me corrections or comments at bfields@umich.edu