Re: How to write patches

[Pete Zaitcev <zaitcev@metabyte.com>]

Jeff's descriprion is very informative, but his emphasis
is somewhat different from what I find difficult with patches.
First, for the life of me I was unable to remeber which
argument goes first (DaveM was mad every time). Second, I kept
forgetting to keep the base tree a diff against that instead of
the latest tree.

So, here is the patch release cycle in my view, with all
small details.

1. I pick a "base" tree which I will hack on. Suppose that
we start with 2.2.17-pre22. So, I download linux-2.2.16.tar.bz2
from Linus place and patch-pre22.bz2 from Alan's place.
THESE MUST BE SAVED after I unpack them.

2. I unpack. Note that I have base release in the directory name.

bzip -d < linux-2.2.16.tar.bz2| tar xf -
mv linux linux-2.2.17-pre22
bzip -d < patch-pre22.bz2| patch -d linux-2.2.17-pre22 -p1

3. One way or another, I make two trees, one of which is "base"
and another is "work".

mkdir linux-2.2.17-pre22-p3
(cd linux-2.2.17-pre22 && tar cf - .)| (cd linux-2.2.17-pre22-p3 && tar xf -)

4. Hack

cd linux-2.2.17-pre22-p3
make oldconfig
(make dep && make bzImage) > build.out 2>&1
........... etc.

The step #4 will take some time, and kernel will get developed
while we sit on it. Normally it takes me anywhere from 3 weeks
to 3 months to come up with something useable.

5. Time to diff and submit, but Oops, Linus published 2.2.17!
Now you will see how it all REALLY works.

5a. Unpack

bzip -d < linux-2.2.17.tar.bz2| tar xf -
mv linux linux-2.2.17

6. Diff your base tree and your changed tree. Do not settle
for .orig files! Diff whole thing!

6a. Get dontdiff from Tigran, it's helpful
wget http://www.moses.uklinux.net/patches/dontdiff

6b. Diff, but notice the argument order!!

diff -urN --exclude-from=dontdiff \
  linux-2.2.17-pre22 linux-2.2.17-pre22-p3 > linux-2.2.17-pre22-p3.diff

6c. In most cases you need to remove junk from your diff,
even with dontdiff.

7. Apply your diff to the new tree (remember,
never touch the base tree):

mkdir linux-2.2.17-p3
(cd linux-2.2.17 && tar cf - .)| (cd linux-2.2.17-p3 && tar xf -)
patch -d linux-2.2.17-p3 -p1 < linux-2.2.17-pre22-p3.diff

If I am lucky, my patch applies cleanly or with a small
fuzz factor. But otherwise there may be a conflict that I
shall resolve by hand:

find linux-2.2.17-p3 -name '*.rej'
# perhaps  cat something.rej >> something && vi something

This part is actually important. If I sent linux-2.2.17-pre22-p3.diff
to Alan, he would try to apply it against then-current 2.2.17
(if not 2.2.18-pre2), get the same conflict, and dump the patch
into the void. Always resolve yourself, do not ride the maintainer.

8. Now I can send the patch to Alan and wait.

9. Once my patch is tentatively applied, say, in 2.2.18-pre2,
I re-download it, and do the whole thing again to make sure
that it was applied right. Alan has a habit of editing patches
on the fly, so I must keep tabs on it.

10. By this time 2.2.17-pre22 base are obsolete so we may
delete them (but evacuate good .config first or you'd start
from defconfig again):

cp linux-2.2.17-pre22-p3/.config linux-2.2.18-pre3/
rm -rf linux-2.2.17-pre22 linux-2.2.17-pre22-p3
# Sometimes I keep linux-2.2.17-pre22-p3.diff a little longer
# after the base moved on, for the sake of slower paced collegues.

And the ball just keeps rolling.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/