First of all, some really authoritative instructions reside at http://metalab.unc.edu/LDP/HOWTO/Kernel-HOWTO.html.
Your kernel source resides at /usr/local/linux, don't under-estimate the importance of the README file that's there, along with the Documetation subdirectory which explains a lot about modules (in modules.txt and networking/net-modules.txt).
As such, it's usually a good idea to make linux be a symbolic link pointing to the actual directory that contains the source code. For example, I delete my linux symbolic link, grab a new kernel and untar it in the directory, rename the newly created directory and reestablish a symbolic link.
/usr/src# tar zxvf linux-2.4.20.tar.gz
/usr/src# mv linux linux-2.4.20
/usr/src# ln -s linux-2.4.20 linux
/usr/src# cd linux
Failure to remove linux
risks a high chance of overwriting
your existing kernel source.
I prefer using symbolic links in order to go back and rebuild prior distrubtions, if it ever becomes necessary.
I almost never apply patches, rather I find it much simpler to just get the entire kernel as a whole and build from there.
Building the kernel isn't complex, you just have to understand what each step does.
/usr/src/linux# make mrproper
This completely cleans out your binary directories. I only do this if I've really screwed something up. Note that this deletes your .config file, so you might want to rename it first! I hardly ever do this.
/usr/src/linux# make menuconfig
This is where you set all the configuration parameters for the kernel. The general gist is that you can build stuff into the kernel, make it a module for loading later, or exclude it all together (saving in size). Your settings typically go in a configuration file called .config. Other commands are make config and make xconfig, should you be using X Windows for the latter.
/usr/src/linux# make dep
This determines all the header file dependencies. Do this whenever you've made a change to the configuation.
/usr/src/linux# make clean
If you've already built the system and are making minor changes, not wanting to re-compile all the objects again, skip this step. If you want to be a purist and make sure you're starting absolutely fresh, do this step.
/usr/src/linux# make bzImage
This compiles the kernel, compresses it, and saves it in arch/i386/boot/bzImage. (Your platform may vary, so read the output string.) It is possible to do a make bzdisk and send the image to a previously inserted floppy for testing.
/usr/src/linux# make modules
If you selected modules <M> for any part of the kernel, you'll have to build them as well.
/usr/src/linux# make modules_install
This moves the module binaries to /lib/modules/kernel_version.
/usr/src/linux# make install
Honestly, I'm not sure what this one is doing in full. But, I believe it moves the System.map file to the root directory so that the kernel can autoload modules properly. I think it also does some tricks with the rdev command to instruct the kernel which drive is the root drive when booting.
/usr/src/linux# cp arch/i386/boot/bzImage /kernel-x.y.z
When I check the kernel at the root with the one in the arch/i386/boot directory, it's usually always different in size and date. As such, I move the kernel manually, to the root directory, using a name that is very clear about what it is.
/usr/src/linux# cp /System.map /boot/System.map
I've found that for some reason the System.map file doesn't always get copied to this location. This seems to be where lilo gets its information when it installs.
"Its primary use is in debugging. If a kernel "oops" message appears, the utility ksymoops can be used to decode the message into something useful for developers. ksymoops makes use of the System.map to map PC values to symbolic values. Note that 2.5 kernels have an in-kernel oops decoder called kksymoops, which does not need System.map."
According to other how-to sources, System.map can (and should) be placed in /boot, rather than /, and can event be renamed /boot/System.map-2.4.20.
I either use this utility, or more likely, edit /etc/lilo.conf by hand. I make an entry for the newest kernel and I always try to leave one old kernel around, just for emergencies.
Editing the loadable modules list
You'll note that in /etc/rc.d/rc.modules there is a command to figure out module dependencies and bunch more to load various modules. If you made some things modules, you'll want to make sure those lines are uncommented.
Reboot the system and invoke the new kernel. You may have to play with some of your configuarion settings to get it all to work right.
Include files which depend on kernel internals should be symbolically linked to your kernel source.
Do NOT delete your kernel source after building the kernel; you need it
in order to build software.