CEG 433/633:
Operating Systems

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 channel on the department's Discord server. I am hoping for a lively discussion leading to good answers and clarifications. Keep an eye on this Discord channel.

Submissions

All submissions are done through pilot. 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 below. This is just a sample and not an actual grading sheet we will use to score your submissions. Each assignment has its own grading sheet at the bottom of the assignment description.  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 on a Linux system. Our grading of your submitted project work includes the execution by us on a current Linux machine. 

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.