"Everything changes and nothing stands still."
— Heraclitus of Ephesus (as quoted by Plato in Cratylus)
The course project gives each team of up to three students an opportunity to propose and complete their own significant modification to Linux kernel behavor. This may be an entirely new capability or it may alter or extend existing functionality. It may be realized through kernel modifications, kernel modules, or some combination of them. The team will evaluate the effectiveness of their modification by developing their own test cases and user and/or kernel test code that can successfully demonstrate and evaluate the new behavior. Students are encouraged to look to their own interests and/or research projects for inspiration, and we will also suggest some possible options.
In either case, each team of students must justify their intended approach in a written proposal document, in order to ensure that the scope of the project is achieveable and meaningful. The proposal document must:
When you are finished writing-up your proposal document, please e-mail it (by the proposal deadline) to firstname.lastname@example.org with the phrase Project Proposal in the subject line.
In addition to submitting a proposal for the project, and (along with your code and other files for your solution and evaluations) a cohesive report that unifies your observations and results for the project, in the last week of the semester your team will also give a project presentation to all the students in the course that (1) gives an overview of the goals of your project, (2) explains core technical challenges that were encountered in your project, (3) describes your approach in detail (including the files, data structures, functions, and other artifacts that were created, modified, or leveraged in your solution), (4) motivates and describes how you evaluated your solution, and (5) presents timing graphs or other data results of those evaluations (along with an assessment of how effective your solution was based on them). Optionally, your presentation may also include a short demo (if possible within the allotted presentation time). The overall project will be graded in part based on this live presentation, as well as based on submitted code and documentation.
As you work on your course project, please take notes regarding (1) what did or did not work out from your original proposal, and how your approach evolved as you worked on the project; (2) what techniques from other labs and studios in the course were relevant to your approach, and how you applied them in your project; (3) how successful your approach was in achieving the goals you had originally proposed; and (4) how (and why) you conducted evaluations of your solution (e.g., using tracing and other means to collect empirical evidence of it's strengths and limitations, and what hypotheses were tested in those evaluations).
When you are finished with your project, please write-up a cohesive report (see next) and e-mail it along with your code files, kernelshark snapshot files, Makefile, etc. to email@example.com with the phrase Course Project in the subject line.
Both your presentation and your project report should document to what extent (and in what ways) the scope, objectives, and plans for your project changed between your project proposal and your submitted project. This documentation should include a discussion of what assumptions were changed (and why they needed to change), what workarounds were needed (and why they were needed), and the details of and reasons for any other differences between what was propoed and what was delivered.
What to turn in when the project is completed: (1) all the code and compilation files used to implement and run your solution (including a Makefile if you used one, etc.); (2) a readme.txt file with the contents described next, and (3) other files (e.g., with screen-shots from Kernelshark) that enhance your report.
The first section of your readme.txt file should include: