CS-3013 Project Assignments

A-Term 2008

This page provides general information about project assignments for the course as well as the specific assignments.

CS-3013 Home Page

Contents

Fossil Lab

For a number of years, WPI students have had a unique resource for programming projects in “systems” courses, namely the Free Open-Source Software Laboratory, commonly known as the Fossil Lab. Last year, the Fossil Lab was upgraded, thanks to a generous grant from Intel. It now comprises thirty Dell PCs, each containing a 2.4 GHz Core Duo processor chip with two processor cores and 2 gigabytes of memory, all connected to a gigabit local area network that is protected from the rest of the campus computing facilities.

With this new equipment comes a new method of usage. Instead of assigning a physical computer in the Fossil Lab to each student or team, students will work with virtual machines. A virtual machine is a simulation of a hardware system with enough performance and fidelity that it is nearly indistinguishable from real hardware. Each virtual machine is represented by a set of files in the student’s directory. To run the virtual machine, the student logs into any PC in the Fossil Lab, invokes the VMware Workstation application, and browses to the appropriate files in his/her directory or desktop. The virtual machines for this course are dual-core Intel 32-bit processors and have a recent version of OpenSuse Linux, version 10.3, and various tools installed.

Within the virtual machine, the student can develop and run programs, build and install the Linux kernel, and do anything else that could be done on his/her own computer with the same software. In addition, the student can suspend execution of the virtual machine and return to the lab later to restart it from another PC. The files representing the virtual machine live in the student’s directory on the Fossil server, so that they are accessible from any seat within the Fossil lab.

To save space on the Fossil server, each virtual machine is a clone of a master virtual machine developed by the professor. Only those pages that are different from the master copy are replicated into a student’s clone; the rest are linked to the shared master. This happens automatically in VMware, so that as the student progresses through the projects, more and more pages are copied over to his/her directory as needed.

Instructions for setting up your virtual machine are provided here (.doc, html).

Students may also copy their virtual machines onto their own PCs and run them there.  Any virtual machine may be run on the free VMware Player application, downloadable from the VMware web site at http://www.vmware.com/download/player/.

Submitting Programming Assignments

Each programming project submitted by a student will be compiled and tested by the graders. In order to make the grading process reasonable, a certain uniformity of project submissions and reasonable standard of programming practice are expected.

Programming projects this term will be compiled and tested on OpenSUSE Linux 10.3 running on a dual-core virtual machine based on the Pentium (i386) architecture.

All student programs should compile without warnings. (It is inevitable, however, that some other parts of the Linux kernel may generate warnings; you are not responsible for those parts.) For user-space programs, the use of the “-Wno_deprecated” switch is not permitted without prior permission from the professor.

For projects that involve modifications to the Linux kernel, the kernel portion will be submitted in the form of patch files, to be explained in class. The grader will start with a previously built kernel and will execute the following commands in a shell to build a student’s kernel.

cd {grader’s source directory}
patch –p1 < {student’s patch file}
make O={grader’s build directory} oldconfig
make O={grader’s build directory}
make O={grader’s build directory} modules_install install

Failure of the patch will result in no credit for the project. The grader will not attempt to correct the patch file and proceed with the build. However, the grader will attempt to contact the student by e-mail to correct the patch file, but credit for the project will obviously be reduced.

All projects will require some user-space programs, either because they are user-space assignments or because they are test programs for kernel projects. Each user-space submission must include source code, header files, a Makefile, a write-up, and test output or any other supporting information. The grader will expect to type

cd {directory containing student’s submission}
make

to compile the components of the project submission and

make clean

to erase all compiled components. User-space submissions must include copies of all non-standard include files. Programs that depend upon kernel .h files must provide separate copies as part of the user-space submission.

Failure of a user-space program to build correctly will result in no credit for that portion of the project.

Finally, all projects should include a write-up explaining the solution. It is preferred that this write-up be either in MS Word format (i.e., .doc) or PDF format. A plain text file will be acceptable for a write-up only if it is short.

Be sure to put your name on every file submitted, including patch files!

Submitting Your Projects

Projects must be submitted using the web-based version of the Turnin system. The instructor will provide accounts to students at the start of term. When accounts are set up, each student will receive an e-mail message with an individual password for the Turnin system. Each student should log into Turnin and change his/her password to something easy to remember. In the event that a password is forgotten, the instructor or grader can reset it upon request. The web-based Turnin system can be accessed from within a virtual machine or from anywhere on the Internet by visiting

            http://www.cs.wpi.edu/~kfisler/turnin.html

Project components should be zipped together. (This is a change from previous instructions.) However, project components should not be partitioned into folders for different parts of the project.

When you submit an assignment, your submission must include not only the solution, but also the test code or test cases and it must be well commented and easy to read by others. Similarly, any output must be cleanly formatted and easy to read by others.

Be sure to put your name at the top of every file submitted as part of a programming project.  You would be surprised at how often students forget this!

“Getting the correct answer” on a programming project is not sufficient to meet the objectives of the assignment. Since operating systems are typically long-lived, frequently revised, complex programs that are used (and maybe abused) by a diverse population of programmers and users, successfully meeting the objectives of a programming project includes testing and paying attention to its robustness.

Programming Project Assignments

Links to programming project assignments will be posted here shortly before the classes in which they are assigned:–

Project #0 – Linux and Virtual Machine Dabbling.
In this project, you will set up your virtual machine and build the Linux kernel according to the specifications presented in class. Details of assignment:– .doc, .html; slides for assignment:– .ppt, .html

Project #1 – Process manipulation in Linux — due Monday, September 8, 2008.
In this project, you will learn to use the Linux/Unix process facilities and to write a primitive command shell. Details of assignment:– .doc, html; slides for assignment: .ppt, html.

Project #2 – Linux Kernel Hacking — due Monday, September 15, 2008
In this project, you will make small modifications to the Linux kernel, and you will learn how to use printk() to debug them. Details of assignment:– .doc, html; slides for assignment:– .ppt, html.

Project #3 – Threads and synchronization — due Thursday, September 25, 2008
In this project, you will learn to use pthreads and various synchronization primitives in Linux. You will implement a shared data structure and the operations to manipulate it. The general design of this project will apply also to Project #4. Details of assignment:– .doc, html; slides for assignment: .ppt, html.

Project #4 – Kernel Message System — due Sunday, October 12, 2008
This is the largest project of the term. In it, you will build a system for passing messages between processes in Linux. It will exercise your understanding of synchronization mechanisms, and it will challenge you in the proper initialization, operation, and testing of a kernel facility. Details of assignment:– .doc, html; slides for assignment:– .ppt, html.