Computer Science Department
Successful completion of 412 requires activities other than
hacking! Below are some examples from previous semesters.
- Inventory of an existing code base
- Code Inventory
- Project proposal (presentation form)
Plan 9 to the PowerPC Architecture
- Technical-topic presentation
Story of a Page
("CART for Linux" project);
the P9PPC project
also has several good examples of technical-topic presentations.
- Project documentation/overview material
- Project blog
- Linux CGroups: Subsystems as Modules
(note: 22 posts in a 15-week semester);
a good blog.
Here are selected entries from the project archive...
- Add loadable-module support to the Linux
- Status: completed by Ben Blum
- AC'97 Audio Device Driver for the Plan 9 research operating
- Status: Completed by Bankim Bhavsar and Deepti Chheda
- Namespace crossings for the Plan 9 research operating
- Status: Proof-of-concept completed by Wes Filardo
- Implement the CART
page-replacement algorithm in the Linux kernel
- Status: completed by Rahul Iyer
- Port the Plan 9 research operating
system kernel to 32-bit PPC Macintosh systems
- Status: proof-of-concept operational; submission in progress.
- An overlay file system for the Plan 9
research operating system
- Status: completed by Chao-Kuo Lin.
- Adapt OpenAFS to the relevant
Linux 2.6 kernel cataclysms
- Status: completed by Jonathan Curley.
Useful proprosal elements (not all elements apply to every proposal):
- Brief summary of what project does (link to summary page is fine)
- Statement on what you want to add
- Features of the existing code base:
- brief outline of chunks of code base (e.g.,
per-platform "modules" vs. common-code "modules"),
with lines-of-code breakdown by chunk
- approximate percentage which is assembly language
- status of compiler/linker/debugger tool chain (if non-standard)
- license flavor
- Elements of what you propose to accomplish:
- Lines of code you expect to write
- Type of code you expect to write (plug-in, device driver, mutate 1% of every existing file, ...)
- Rough count of files you intend to add/change (add one 2-file module; lightly edit 100 files, ...)
- Rough milestone list (four or five phases, with a rough estimate of how many weeks per phase)
- Vague responsibility breakdown (Terry will work on X, Kelly will work on Y; or maybe:
Pat will be the hardware expert and Lee will be the software expert)
- What necessary documentation do you already have?
- What necessary documentation are you hoping you can find?
Does the work depend on somebody agreeing to release something
- Are you expecting to rely on some body of source code as
as documentation? If so, explain briefly.
- Expected start-up obstacles:
- Does the work depend on a language you don't fully know?
- Will it be necessary to install, configure, and learn some emulation environment?
- Is there a tool which you will need to adjust/extend for your work?
- Are you proposing to extend a protocol which you don't yet know?
- Is there some thing which you could discover which would put a stop
to the whole project?
- Is there some element of outside-CMU cooperation which might fall through?
- Hardware/space resources:
- How many machines of what type will be necessary?
- Which machines do you plan to provide? Do you have spares?
- What equipment, if any, do you hope to install in the 412 lab?
How many IP addresses do you expect to need?
These are probably elements for a second draft:
- As far as you know, are others working on similar goals?
- How will you test your work?
- What is the standard acceptance process for code in this project?
- Project road-map: maybe a 20-item todo list, or a boxes-and-arrows
dependency chart showing what needs to happen before other things.