Project 1: Warm-up with Linux

Important Dates

Due: Monday, 2/17, whenever.


The project is just a light warm-up to Linux kernel development. You will build a kernel, get it to run in some kind of virtualized environment, and change it a little to prove that you can indeed do so. Specifically, you'll add some counters into the Linux ext2 file system code, and add a system call to get the value of that counter.


Part 1: Kernel Building and Running

The first part of project has a number of steps. First thing you should do: download a clean kernel from . We recommend the 3.13.1 kernel which is recent and stable, both good properties.

For this project, you can build and run Linux in any number of ways. One easy way to run Linux without a lot of virtual machine setup and pain is to use User-Mode Linux (UML), which basically allows you to run Linux as a user process on a Linux machine. Read more about it here online -- though be warned, some of that stuff is out of date.

To build Linux for use in UML mode, you should follow instructions here. The steps are pretty simple; the only tricky thing is configuration, which is probably easiest with make menuconfig ARCH=um . In this project, you should select a 32-bit kernel (not 64-bit), and make sure to include a bunch of file systems, specifically ext2 (as we'll be using that below).

Once built, you'll have to find a disk image to boot the kernel from. This page lists a bunch; make sure to pick a 32-bit image (if you followed instructions and built a 32-bit kernel!); the more fully loaded images have lots of useful binaries in them, such as gcc, so please use one of those (e.g., Gentoo 32-bit).

Now you are ready to boot the kernel. Again you can follow instructions from the UML website but they are simple: ./linux ubda=NAME_OF_IMAGE mem=256m (or something like that). Make sure to specify how much memory as well as the correct path to the boot image you downloaded.

If you've done all of this correctly, Linux will boot, and you will be able to log in as root with no password. Now onto the harder part: actually doing something in the kernel!

Part 2: Kernel Hacking

In this part of the project, you'll actually modify the kernel to show that you can indeed do so. What you'll do is simple: add a counter to the ext2 file system, and then show that you can query that counter.

The ext2 counter you should add will count how many times fsync() has been called while ext2 is running. Thus, you should look in file.c in the fs/ext2/ directory, and add in the declaration of a global counter, as well as a counter increment, in that file. Pretty easy!

As a debugging step, you should add a printk() into the fsync() code; you can see the results of this printk() by running a program within your UML Linux that opens a file, writes to it, and calls fsync() (do this before adding the system call piece). To see its output, type dmesg at the command prompt.

To test this out, you might also want to make a separate partition for ext2. To do this, you can run Linux UML with ubdb (the b device) set to another image (it doesn't matter what is in it). You can then, once booted, use mkfs to make a new file system, and mount to mount it.

Finally, you need to add a new system call to your kernel, to get the value of the counter. Read online to find out how to do this. When done, you should create a program within UML that calls your system call and gets the value of the counter both before and after calling fsync() . Note: we do not spell this part out, so you have to look around a bit and figure it out. One key thing to realize: adding a system call into UML is slightly different than adding one to raw Linux for x86 for example.

Handing It In

To turn this in, you will create a screencast demo of what you have done. Show the entire process: how you built the kernel, how you run it, what you changed in it, and a demo of how that all works. The screencast should be something I can view easily on a Mac, i.e., Quicktime. The screencast should also be quick: less than 5 minutes.

Copy the screencast into your handin directory: ~cs736-1/handin/login/p1 where login is your login.

You should also copy relevant files that you have changed into the handin directory, e.g., file.c from ext2, and a few others.

Please also include a README file. In there, describe what you did a little bit. The most important bit, at the top, however, should be the authorship of the project.