How to write patches

How to write patches

[Sourav Sen]

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

-
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/

Re: How to write patches

[Daouda LO]

Sourav Sen <sourav@csa.iisc.ernet.in> 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
-
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/

Re: How to write patches

[Pete Zaitcev]

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/

Re: How to write patches

[Matthias Andree]

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
-
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/