Re: Why from there?

Brion Vibber (
Wed, 13 May 1998 19:49:18 -0700

Riley Williams wrote:
> There IS a simple solution, although it's a little more work for the
> people creating the upgrade patches, which is to put the correct paths
> in them. I don't have one to hand, so the following is a fabricated
> part-patch to upgrade from kernel 9.8.7 to 9.8.8 that should do it:
> Q> --- linux-9.8.7/drivers/char/serial.c Thu May 14 00:09:12 1998
> Q> +++ linux-9.8.8/drivers/char/serial.c Thu May 14 00:09:19 1998
> Note that the FIRST element of the path shown DIFFERS between the two
> paths, and my understanding of how patch works indicates that the
> above would result in it taking the contents of the existing file as
> labelled by the --- line and copying it to that named by the +++ line
> with any patches indicated being made.

My experience is that it takes the file named by the +++ line and
patches it. The file specified in the --- line does not need to exist at
the time of patching. For instance, here are the first few lines of the
2.1.100 to 2.1.101 patch:

diff -u --recursive --new-file v2.1.100/linux/Documentation/ARM-README
--- v2.1.100/linux/Documentation/ARM-README Sat May 2 14:19:50 1998
+++ linux/Documentation/ARM-README Fri May 8 00:42:37 1998
@@ -1,15 +1,12 @@
- ARM Linux 2.1.78
+ ARM Linux 2.1.99

I don't have a "v2.1.100" directory _anywhere_ on my system. All input
files were under /usr/src/linux, and all output files were under

Now, the way I tend to upgrade my kernels is quite simple:

cd /usr/src
# We want to keep version numbers up to date so let's rename our
source dir
mv linux-2.1.100 linux-2.1.101
# linux is a symlink to linux-2.1.100, so now let's update it for the
new version
rm -f linux
ln -s linux-2.1.101 linux
# Okay, now we apply the patch
bzip2 -dc /download/kernel/patch-2.1.101.bz2 | patch -p0

Basically, I make sure that /usr/src/linux always points to the copy of
the kernel source that I am working on at the time. This keeps my
include files up to date - /usr/include/linux and /usr/include/asm
always point to subdirectories of /usr/src/linux - and I know that
kernel tarballs and patches will always go into the directory that I
want them to because I have set /usr/src/linux to point to the desired

If I want to keep my old source tree as a backup when upgrading with a
patch, all I need do is make a new directory for the new kernel, point
/usr/src/linux to it, untar the old kernel (which incidentally ensures
that I have a nice clean copy to patch), and apply the new patch:

cd /usr/src
# Make the new source dir
mkdir linux-2.1.101
# Update our link to the new dir
rm -f linux
ln -s linux-2.1.101 linux
# Untar a clean copy of the previous kernel
bzip2 -dc /download/kernel/linux-2.1.100.tar.bz2 | tar xvf -
# Patch it!
bzip2 -dc /download/kernel/patch-2.1.101.bz2 | patch -p0

It's simple, it's clean. I don't need to muck around with my include
directories every time I try a new kernel. I don't need to worry about
input and output directories, I always know _exactly_ where everything
is going to go: where I tell it to. I just change the symlink to where I
want my kernel and I untar & patch away! What is so wrong with this

You've mentioned the possibility of phantom files left over from people
untarring a new kernel over an old one... First of all, if people are
doing this, they shouldn't be! And if it's actually causing a problem,
then this is a problem with the Makefiles, not the users - the Makefiles
shouldn't be specifying files that shouldn't be compiled into the
kernel. (Unless you mean the possibility of stale object files that are
'newer' than the source files, which is probably why there is a
direction to run 'make dep; make clean' if you want to make sure that
everything is cleanly built after configuring the kernel...)

-- brion vibber (

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to