On Thu, 22 Aug 1996, Darren Crane wrote:
>
> 2.0.14 vs. pre2.0.7
> ------- --------
> 10 secs 1.5 secs hmmmmm.....
Would you be willing to do a few tests for me, please?
The first test is simply to determine exactly _which_ kernel breaks. The
fastest way to do that is to do a "binary search": start off with 2.0.10, for
example, and if that doesn't show the problems go to 2.0.12, and then to
2.0.11 if .12 is broken..
If you're using patches, this isn't actually too hard: you can "reverse"
a patch by using the "-R" flag, so you can go backwards too. For example,
if you have 2.0.12 and want to go backwards to 2.0.10, you can do
cd /usr/src/linux
zcat < xxx/patch-2.0.12.gz | patch -p1 -R
zcat < xxx/patch-2.0.11.gz | patch -p1 -R
/* and if everything went ok: */
rm `find . -name '*.orig'`
The more you can narrow down exactly which patch breaks, the better: it helps
developers a LOT to get even just the exact patch that broke something, and
if you are adventurous and know how "patch" works, you can even try to
pinpoint exactly which _part_ of the patch broke for you (but you don't have
to do that - it's strictly for people who _really_ know the kernel).
Linus