6.828 Fall 2012: Final project
In the second half of the course you'll work on an operating systems
project of your choice in teams of two or three. The goal is to have
fun and explore more advanced O/S topics; you don't have to do
We'll grade you on how much you got working, how elegant your design
is, how well you can explain it, and how interesting and creative your
solution is. We do realize that time is limited, so we don't expect
you to re-write Linux by the end of the semester. Try to make sure
your goals are reasonable; perhaps set a minimum goal that's
definitely achievable and a more ambitious goal if things go well.
Schedule and Deliverables
- Oct 19: Form groups of 2 to 3, e-mail us.
- Oct 26: Submit a proposal at
the course website, just a paragraph or two.
- Week of Oct 29: first project conference with 6.828 faculty --
we'll schedule a meeting with each team to discuss your proposal.
- Weeks of Nov 21/26: second project conference.
- Dec 7: submit source code along with a two-page write-up.
Put the write-up under the top-level source directory with the
- Week of Dec 10: final conference with faculty, with demonstration.
- Week of Dec 10: short in-class demonstration.
Since most of you will be working in groups for this lab assignment,
you may want to use git to share your project code between group members.
We have provided each group a shared repository on our submission server.
After handing in your group proposal, you can access your group's
shared repository with this URL:
You will need to decide on whose source code you will use as a starting
point for your group project.
That group member should run the following commands to place his or her
JOS (or xv6) source code into the group repository.
athena% cd ~/6.828/lab
athena% git remote add group ssh://firstname.lastname@example.org/project.git
athena% git checkout -b project
Switched to a new branch 'project'
athena% git push -u group project
Counting objects: 4343, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3010/3010), done.
Writing objects: 100% (4343/4343), 11.65 MiB | 1.53 MiB/s, done.
Total 4343 (delta 1652), reused 3990 (delta 1329)
* [new branch] project -> project
Branch project set up to track remote branch project from group.
The other members of your group can then checkouts the project from
this shared group repository, as follows:
athena% git clone ssh://email@example.com/project.git lab
Cloning into 'lab'...
remote: Counting objects: 4346, done.
remote: Compressing objects: 100% (2690/2690), done.
remote: Total 4346 (delta 1654), reused 4343 (delta 1652)
Receiving objects: 100% (4346/4346), 11.65 MiB | 2.68 MiB/s, done.
Resolving deltas: 100% (1654/1654), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.
athena% cd lab
athena% git checkout project
Branch project set up to track remote branch project from origin.
Switched to a new branch 'project'
At this point, all of your group members should be able to pull and push
commits from the shared repository by running git pull and
git push on the project branch, respectively.
Pushing code to our repository is equivalent to submitting your project.
As before, you can submit as many times as you want. We always take
the latest submission before the project deadline.
Note that the shared project repository authenticate you using
the same public key that you have used to submit your previous labs.
If for some reason git clone, git pull
or git push promote for a password,
you can fix the problem by running make handin-prep
in your JOS directory to update your public key with our submission server.
Keep in mind that git only tracks files that you have explicitly committed, so
you may want to run git status periodically to see if there are any
lingering files in your checkout that you haven't committed.
You can use git add filename to tell git about files you
would like to commit with the next git commit command. If there are files that
you will never want to commit, and you want to prevent them from showing up in
the output of git status, you should create a file named .gitignore and
add the filenames that you'd like git status to ignore to that file,
one per line.
Here's a list of ideas to get you started thinking -- but you should
feel free to pursue your own ideas.
- Build a virtual machine monitor that can run multiple guests (for
example, multiple instances of JOS), using
x86 VM support.
- Do something useful with the x86
Execution Technology. For example, run applications without having
to trust the kernel.
Here is a recent paper on this topic.
- Fix xv6 logging to support concurrent transactions, and generally
have higher performance, perhaps taking ideas from Linux EXT3.
- Use file system ideas from
ZFS, or another advanced file system.
- Add snapshots to a file system, so that a user can look at
the file system as it appeared at various points in the past.
You'll probably want to use some kind of copy-on-write for disk
storage to keep space consumption down.
to provide fine-grained control over what privileges processes have.
- Build a
distributed shared memory (DSM) system, so that you can run
multi-threaded shared memory parallel programs on a cluster of
machines, using paging to give the appearance of real shared memory.
When a thread tries to access a page that's on another machine, the
page fault will give the DSM system a chance to fetch the page over
the network from whatever machine currently stores.
- Layer software
RAID-5 over an array of disks, to increase
fault tolerance and performance.
- Allow processes to migrate from one machine to another over
the network. You'll need to do something about the various pieces
of a process's state, such as file descriptors in xv6.
- Implement paging to disk
in xv6 or JOS, so that processes can be bigger than RAM. Extend your pager
- Implement mmap() of files
for JOS or xv6.
- Implement loadable kernel
modules to extend the xv6 kernel to replace or extend subsystems of the
xv6 kernel. For example, make the file system a kernel module so that you can
add a kernel module to read DOS file systems, or replace the xv6 file system.
- Use xfi to sandbox code within a process.
- Support x86 2MB or 4MB pages.
- Modify xv6 to have kernel-supported threads inside processes. See in-class
uthread assignment to get started. Implementing scheduler activations
would be one way to do this project.
- Implement ideas from the Exokernel papers, for example the packet filter.
- Make JOS or xv6 have soft real-time behavior. You will have to identify
some application for which this is useful.
- Make JOS or xv6 run on 64-bit CPUs. This includes redoing the virtual
memory system to use 4-level pages tables. See reference page
for some documentation.
- Port JOS or xv6 to a different microprocessor. The osdev wiki may be helpful.
- A window system for xv6 or JOS, including graphics driver and mouse. See
page for some documentation. sqrt(x) is
an example JOS window system (and writeup).
- Implement dune
to export privileged hardware instructions to user-space applications in JOS
- The linux kernel uses read copy update
to be able to perform read operations without holding locks. Explore RCU by
implementing it in xv6 and use it to support a name cache with lock-free
- Intel recently announced transactional
memory support for its upcoming processors. Implement support for
Intel's TSX in the QEMU emulator. A follow-on project would be to explore the
use of Intel TSX primitives in writing concurrent software, such as extending
a small multi-core operating system (based on 6.828's xv6) to use
- If you can't think of anything, it's OK to do the labs from 2011 that you
have not already done (for example, the network stack).