Messages in this thread Patch in this message | | | Date | Wed, 13 May 1998 19:49:18 -0700 | From | Brion Vibber <> | Subject | Re: Why from there? |
| |
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 linux/Doc umentation/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 /usr/src/linux.
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 directory.
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 system?
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 (brion@pobox.com)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |