Lab 2 tips

Compiling your kernel, and making it work:

Building a kernel Setup:

Retrieve the kernel source from one of the locations in the project description.
Expand the tarball with the command tar jxf linux-2.4.26.tar.bz2
Go into the linux-2.4.26 directory, and either use the make menuconfig command to configure the kernel options, or preferably, use the supplied kernel config (copy it into the kernel directory, and name it .config file), and then run make oldconfig.
Run make dep -- This regenerates the file dependencies in the kernel tree.

Building a kernel: (After each change)

Run make clean -- The make system is supposed to automatically determine what needs to be recompiled. In Linux it does not work correctly. It has been fixed in the new 2.6 kernel series. If you change something in the source, and it doesn't seem to take effect, run make clean and try again.
Run make bzImage -- This generates a compressed kernel image in the file arch/i386/boot/bzImage

Using your new kernel

The lab machines are setup to use the GRUB boot loader. They all should have a cs111 entry (on boot). This entry points to the file /boot/cs111/bzImage So, all you need to do is copy the arch/i386/boot/bzImage to /boot/cs111/bzImage, and then reboot (You can use the menus to reboot, or hit CTRL-ALT-F1 to go to a text terminal, then hit CTRL-ALT-DEL. The system will reboot properly). When the system reboots, there will be a menu where you can select the cs111 entry (The other entries are like linux, failsafe, etc).

If you are using Mandrake 9.2 on your home computer, go into the mandrake control center and look at the boot loader section. You can add an entry to point to any file you'd like to use. *WARNING* you don't want to overwrite the existing entry, or the file it points to. If there's a problem you won't have anything to use to go back and fix the problem. *Leave the working entry alone, so you can use it to fix any problems.*

Saving your work:

The kernel source is very large and your SEASnet disk quota is probably not large enough to keep the kernel source in your home directory. Additionally, your home directories are on a remote file server, so it will be faster to use a source tree that is on the local machine. You should create a directory in /tmp to work in. However, you should not leave source trees on the local machines because they take a lot of space, the /tmp directories are not backed up, and if the machines crashes it will just be reinstalled. In other words, you want to use the source tree temporarily in the /tmp directory on the local machine, and then save your changes to files in your home directories. One approach is to save copies of the files that you've modified, which will be fairly few in number. You can then expand a fresh copy of the kernel source, and copy your files in when ever you want to work on your project.

Another approach is to generate a diff from the original source. This is documented in the file: linux-2.4.26/Documentation/SubmittingPatches .

To generate a diff, move your directory tree to some other name: mv linux-2.4.26 mylinux.

Expand a fresh 'clean' tree next to it:tar jxf linux-2.4.26.tar.bz2.

There are many files that are generated when you compile the kernel or configure it, luckly someone keeps a list of those files, so you can easily exclude them. Download the list from http://www.moses.uklinux.net/patches/dontdiff.

Now you are ready to generate a diff. diff -burN -X dontdiff linux-2.4.26 mylinux > mychanges.patch.

You can look at the mychanges.patch file and see that it has all your changes in it, with a bit of context around each change.

If you created newfiles in the modified source directory, even files with debug output, or backup copies, they will be included in the diff. You should remove these files before generating the diff for your project submission.

To use your patch to go back to a your modified kernel tree, expand a fresh source tree tar jxf linux-2.4.26.tar.bz2
cd into the linux-2.4.26 directory
Use the patch command patch -p1 < ../mychanges.patch.

This will apply the diff to the source tree, getting you back your changes.

*WARNING* Before relying on the diff/patch method, try it out to make sure you've done it right. i.e. before deleting the mylinux source tree, try using patch and verify that you can recover your changes.

Tips:

Kernel trees take up a lot of space. If you clean up after yourself, by deleting source trees everyone who uses the lab computers will be a lot happier.

If you find a source tree, even if it has the name linux-2.4.26 or linux-2.4.26-fresh-source-untouched, don't use it, just uncompress a new tree for yourself. You never know what someone has done to a source tree.

The printk command as listed in the lab manual will probably only get logged to /var/log/messages. You might also be able to see the output of your printk messages by running the dmesg command. To get printk's to show up on the screen, try using printk(KERN_CRIT "fmt-string...). This means it's a critical message.

If you don't take some special care in compiling your test program, you'll probably have a problem using the macro to generate the stub for your systemcall. In your test program, you should: #include <linux/unistd.h> in order to get the stub macros, as well as the name to number mappings. The problem is that by using < and > on the include line, you are telling the compiler to use the standard system header files in /usr/include. However you should not modify these files, but should only modify files in your source tree. (On the lab machines you don't have permission to modify those header files.) In order to rememdy this situation, you should give gcc the option -isystem <DIR> when compiling your user space test program. The value of <DIR> should be the include directory in your kernel source tree, i.e. -isystem linux-2.4.24/include

Before changing any of the kernel code, you may want to build a stock kernel to make sure that you have the build procedure correct.

The LXR - Linux Cross Reference - page is an excellent cross reference for the linux kernel. You can search to find where particular functions are defined, where they are used, etc.
^^^^^ USE THE LXR! ^^^^^