• New VirtualBox VM and 2 Options for building the kernel
• Adding new user accounts to your VM
• Designing Good Demo Test Programs

Many thanks to Cal Smith who helped us streamline the .config file for faster kernel builds.

We are going to start with a new virtualbox image for lab 3 and all remaining labs, and we are going to start with a fresh copy of the Linux source for lab3.

Log into your machine as your cs45 account and do the following:

1. start up virtualbox
2. copy over the new virtualbox image, start with new linux source, and a new .config file into your /local/you_n_pal/ subdirectory:

   # grab new virtualbox VM:
   cd /local/me_n_pal
   cp -r /local/vm/ubuntu-12.04.3-NOINITRD/ .
   
   # start over with new source code, with new config file
   mv linux-2.6.32.44 lab2_linux
   tar xjf linux-2.6.32.44.tar.bz2 
   cd linux-2.6.32.44
   cp /local/vm/config-noinitrd .config
   make menuconfig
   
   # these files are also available in scratch:
   /scratch/vm/ubuntu-12.04.3-NOINITRD/
   /scratch/vm/config-noinitrd
   

3. Follow new instructions on the virtualbox guide for adding the NOINITRD virtualmachine setting up virtualbox VM

   Also, on this new virtual machine, set your port number:

   From the Settings menu choose:
      Network
        Port Forwarding
          HostPort:  change this to your group's port number
   

Note: after your Lab 2 demo, I strongly suggest that you remove the old VM image from VirtualBox just to avoid confusion with accidentally booting up the wrong one. To do this:

1. start up virtualbox
2. choose the STARTHERE VM
3. remove it (from the Machine menu, choose Remove)

Then from here on out you will only have the option of booting the NOINITRD VM.

Building and Installing the Kernel 2 Ways

Together we are going to build and install the kernel in two different ways on the linux kernel on your VirtualBox VM.

1. We are first going to follow the slightly modified Option 1 way of building the kernel: build and install kernel_image and kernel_headers packages

   Note some changes on the Virtualbox guide to the way in which you will build kernel packages from here on out:

   --initrd --append-to-version  are no longer used
   

2. Once you have built, installed, and booted the lab3 version of your kernel packages, we are going to now try to build following the "Option 2" steps: VirtualBox guide for CS45

For some testing you may want to add additional users on your VM, to do this run adduser as root to add a new user account to your system (choose a unique user name, make-up the rest of the stuff):

$ sudo adduser username 

You can switch from one user to another by doing:

$ sudo su username

If you want to give this new user permission to run sudo, you can add this user to the sudo group by running usermod:

$ sudo usermod -a -G sudo username

Another way to do this is to just edit the group file adding the user name to the sudo group:

$ sudo vi /etc/group
sudo:x:27:swatcs,username1,username2,...

You can list the group membership of a user by:

$ sudo groups username

When demo'ing your labs, you want to make sure you can run a single system call at a time and then show me the results of that call or action. Usually the best way to do this is to write some test program(s) that are menu-driven:

repeat:
(1) enter your choice for the next action
(2) perform it

Then, after (2), determine how to demonstrate to me that (1) worked correctly. This may involve looking at top, /proc, and other utility output. It may also involve writing test programs that allow you to infer the values of some fields and also demonstrate that your system call is able to return the correct values for different fields. For example, write a simple test program that will accumulate a lot of user time when run, and then show the results of calling procinfo with the pid of that running test program.

For lab 2, you could also likely write a demo program that just takes as a command line argument the pid of the process to pass to your system call. However, for subsequent lab demos menu-driven is absolutely what you want.

It may also involve having some debug output in your kernel (however, don't go nuts here...there should not be so much printk output that it is difficult to see what the heck is going on). For some labs, I'll have you implement a print_some_info system call, which you can then use to demonstrate the actions of previous system calls. Remember that sudo dmesg -n 7 will echo printk's to the console.

As you implement, debug and test the correctness of your lab, you may want additional test programs that make a sequence of system calls (non-menu driven) for quicker testing. However, your demo test program should be menu-driven and slower (one thing at a time, show me the results and show me how your can verify that they are correct).