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:
# 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-18.104.22.168 lab2_linux tar xjf linux-22.214.171.124.tar.bz2 cd linux-126.96.36.199 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
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 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
$ sudo adduser usernameYou can switch from one user to another by doing:
$ sudo su usernameIf 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 usernameAnother 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
repeat: (1) enter your choice for the next action (2) perform itThen, 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).