College of Engineering & CS Dayton, Ohio 45435-0001

CEG 433/633: Operating Systems Prabhaker Mateti Project Expectations

The project for an operating system course typically has at least the following dual goals:

• to make you use an existing OS in a skilled way in building larger programs than you have so far, as well as
• to make you think about the design of such an OS.

The following are applicable to all your work (projects, home work, and exams) in the course, and will not be repeated in later handouts.

Plagiarism

These projects must be work done solely by you, except for any of the parts I provide.

Quality of Code

The implementation must be in C or C++ demonstrable on our Unix systems.

Subsequent parts build on the code you write. Make sure your source code quality is high. It is a subjective judgment. To be concrete about it, I suggest a few specifics below. Follow them vigorously, even if unwillingly. As you become a mature programmer, you will (guaranteed ;-) come to appreciate the benefits of this rigidity in style.

Keep the routines (methods), and files small. No routine should exceed, say, 20 lines (not counting comment lines). No file should exceed, say, 200 lines, or 4000 bytes. Some times a method is no bigger than a couple of lines. Do not hesitate to turn a code segment into a routine/method because it is then going to be called just once.

For every routine/method, carefully document its pre- and post-conditions. Caller is expected to satisfy the pre-conditions prior to the call. The method is designed and coded assuming that the pre-condition holds. To improve robustness, you may want to check the pre-condition, but, it is not expected that you do. The caller, upon return, expects that the called routine has accomplished what has been described in the post-condition.

Clarifications

Part of (large) program development is independently, but wisely, deciding what to do for certain "erroneous" situations. Should we ask the professor for what to do for every possible error you can think of? [Answer: No. You think about it. You take a reasonable action. You document this in your source code, and in ReadMe.txt. And, be ready to defend your choice should it be questioned.]  Should SimDisk() constructor printf or cout>> an error message? [No.] When does/should mkSimDisk() return a zero? [Think.]  Remember that one of the goals of CEG 433/633 is to make you think about larger programs. Part of this is to supply missing, but needed, details in the problem description.

Post all your questions, helpful comments, criticisms, and suggestions regarding this project to our news group: wright.ceg.433. I am hoping for a lively discussion leading to good answers and clarifications. Keep an eye on this newsgroup.

Submissions

All submissions are done using the turnin program located in ~pmateti/CEG433/bin on all the Linux machines in the OSIS Lab. Its first argument is the name of the part of the project, which is uppercase P followed by one digit, e.g., P1. Following this are the names of files that you intend to submit. So, for this part, the command line may look like this:

turnin P1 ~/433/*

assuming that you did a make clean just before invoking this command.

The following files, with names exactly as indicated, must always be submitted.

• ReadMe.txt: This file must include (i) your name, and e-mail address, (ii) a listing generated by ls -l of the directory containing your project files, (iii) an explanation of how the project was accomplished using the above files, and (iv) highlights both the good points and bugs and problems that it has.  In (iii) make sure you are documenting the design, not just coding, of your program. 
• Makefile: Must have the targets test, $(PROJECT), and clean properly prepared. The value for PROJECT must change from P1 to P4 as we progress. The Makefile must set
  CFLAGS = -c -g -Wall -ansi -pedantic
• TestScript.txt: Think about how you will verify that your program is functioning correctly. Note that the shell of P1 reads from stdin and writes to stdout/stderr. So, we can prepare a text file TestScript.txt of input for our shell and run it as shell < TestScript.txt The test run should demonstrate that all the features of the current part are exercised.
• typescript of a successful make test. If I cd to your directory, and run the command make test, a clean, a compilation of all files, a link of all object code files into the executable $(PROJECT), followed by a successful test run should happen.
• Source code files, with your choice of names. These must have been pretty printed in a standard style. Learn to use indent -kr.

Grading Sheet

A typical grading sheet is shown here.  We try to read your code.  But we depend mostly on observed execution of your code.

All work for this course is expected to be done in the Operating Systems and Internet Security Lab (429 RC) using Linux.  Our grading of your submitted project work includes the execution by us on these machines. 

Bonus points are awarded in recognition of good work, in addition to the max possible points.  Quality is subjectively judged.  Merely turning in a file will not receive full score. Bonus points are used not in "curving" but in possibly pushing an individual student's grade up.

Subsequent parts build on the code you write. So, make sure your source code quality is high.

Some of the above have a cascading effect.