 Computer Science Department |
 |
 |
 |
 |
 |
15-412 Projects
Deliverables
Successful completion of 412 requires activities other than hacking! Below are some examples from previous semesters.
- Inventory of an existing code base
- Code Inventory (P9PPC project)
- Project proposal (presentation form)
- Porting Plan 9 to the PowerPC Architecture (P9PPC project)
- Technical-topic presentation
- The Story of a Page ("CART for Linux" project); the P9PPC project also has several good examples of technical-topic presentations.
- Project documentation/overview material
- README and code map (NetWatch project)
- Project blog
- Linux CGroups: Subsystems as Modules (note: 22 posts in a 15-week semester); the NetWatch project also has a good blog.
Project Archive
Here are selected entries from the project archive...
- Add loadable-module support to the Linux cgroups infrastructure
- Status: completed by Ben Blum
- AC'97 Audio Device Driver for the Plan 9 research operating system
- Status: Completed by Bankim Bhavsar and Deepti Chheda
- Namespace crossings for the Plan 9 research operating system
- 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.
Proposals
Useful proposal 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)
- Documentation
- 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 to you?
- 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?
- Hazards?
- 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.
[Last modified Thursday September 24, 2015]