Project: Implementation

The final step in the class project is to submit your implementation. Each group should submit a single implementation by email in a .tar.gz or .zip file. Send the email with the subject [Advanced OS] Project Implementation, and please CC all group members on your email so everyone can verify the work has been submitted. Implementations are due at College’s work turn-in deadline, so I cannot offer any extensions without an approved incomplete.

In addition to the code you have been diligently writing for your project, your code archive should include a short README file that explains what your project does, how I can use it, and how I should interpret the output from your running project. Please also indicate clearly in the README whose kernel implementation you started with for the project The README does not need to be long or especially detailed; just share enough information so I can easily run your work and understand what it is doing.

Your project work builds on code for an earlier kernel implementation, and that kernel implementation may fall short in some areas where the project is evaluated. For the most part, I will only evaluate the code you’ve written for the project; I will look at the differences between your project code and the kernel you started with to understand your work. There may be areas where your project disrupted an otherwise-reasonable organizational scheme in the initial kernel code, so you may lose points for not updating that organizational scheme in the project implementation. As an example, you may have started with a kernel that implemented all five system calls in a single function with if/else blocks. If your project included additional system calls you should probably break that large system call handling function into separate functions for clarity.

Your implementation will be graded using the following rubric:

Rubric

Component	3	2	1	0
README	N/A	N/A	The archive includes a short README that acknowledges the source of the kernel code you started with, and gives a brief description of how to run the project and interpret its output.	The README file is missing a required element, or is missing altogether.
Organization	The project implementation is carefully organized into separate files and functions in a way that makes it easy to find key components and understand how they interact.	The project implementation is generally well-organized, but has some areas where code could be divided up into separate functions or files to make the system easier to understand.	The code is mostly disorganized, but shows some signs of effort to impose an organizational scheme.	The project is written almost entirely with overly-long functions crammed into a small number of files with no logical connections between code within most files.
Documentation	The project code includes explanatory comments at the top of every function, and sufficient comments within functions and near datatypes to make the code easy to read and understand.	Most functions are documented and most code includes reasonable comments, but some areas are lacking.	Much of the project has adequate comments, but a significant number of functions or complex blocks of code are uncommented.	The project code has very few comments and is difficult to understand.
Errors and Warnings	The project compiles without errors or warnings	The project compiles without errors, but contains a small number of innocuous warnings.	The project compiles without errors, but produces many warnings that may indicate underlying issues.	The project does not compile correctly.
Functionality	The project runs and produces meaningful output. That output should be interpretable based on the README file and examples from your group's presentation.	The project runs and produces output, but that output is either difficult to understand or deviates from what the documentation says to expect. Alternatively, the project may produce the expected output sometimes, while crashing on other runs.	The project runs and produces some output, but crashes most or all of the time.	The project does not run.
Completeness	The project implementation represents a "complete" artifact that adds some meaningful new functionality to the kernel. The functionality does not have to align perfectly with your proposal, but should still be a coherent collection of pieces that allow you to do something new with the kernel.	The project implementation is mostly commplete, but one or two important pieces are missing or broken. The functionality you added cannot be used in a meaningful way without fixing these remaining pieces.	The project implementation is incomplete, but the scope of work completed was still sufficiently ambitious for the five-week timeline.	The project implementation is incomplete, and the completed work does not seem to reflect five weeks of significant effort.