Hi,
This question may seem naive, but can anyone tell me if there is any
structured way of writing patches?
I mean suppose I want to implement some
kernel mechanism, and I define my data structures etc. and made most of
the code as loadable module to start with, but still I am having to
change some parts of the kernel code at the development time, and I
want to make that change using patches, so that I do not have to browse
thru the files to change the code as I debug.
Is there any structured way of doing this?
Happy New Year
Sourav
Sourav Sen <[email protected]> writes:
> Hi,
>
> This question may seem naive, but can anyone tell me if there is any
> structured way of writing patches?
>
> I mean suppose I want to implement some
> kernel mechanism, and I define my data structures etc. and made most of
> the code as loadable module to start with, but still I am having to
> change some parts of the kernel code at the development time, and I
> want to make that change using patches, so that I do not have to browse
> thru the files to change the code as I debug.
>
> Is there any structured way of doing this?
have a look at:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0011.2/0151.html
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
On Fri, 29 Dec 2000, Sourav Sen wrote:
>
> Hi,
>
> This question may seem naive, but can anyone tell me if there is any
> structured way of writing patches?
1. get a base tree, e. g. 2.2.18, and unpack it into /usr/src
(rename your old /usr/src/linux first)
2. rename linux you got in 1. to linux-2.2.18 or whatever is appropriate
3. cp -a -l linux-2.2.18 linux-2.2.18-ss1 (your initials and a number)
that makes hard links which speeds up diff a lot
WARNING: IF YOU HAVE AN EDITOR THAT DOES NOT RENAME THE ORIGINAL TO A
BACKUP FILE NAME, YOU MUST NOT USE -l HERE! (You'd end up editing the
copy AND the original and your diff would be empty.)
(break link and copy on write would be a cool feature for the fs...)
4. ln -sfn linux-2.2.18-ss1 linux
5. go edit your ss1 tree with an editor that makes backups by renaming
before it writes out its files (emacs does in default configuration,
vi does not!)
6. if your -ss1 kernel is ready for release, save your .config from
/usr/src/linux somewhere you'll find it (for convenience).
7. cd /usr/src/linux ; make distclean
8. cd /usr/src
9. diff -Nur linux-2.2.18 linux-2.2.18-ss1 | gzip -9c >patch-2.2.18-ss1.gz
With diff, that's OLD NEW (or FROM TO), nothing really difficult since
it's the same way as in mv or cp.
--
Matthias Andree