Screen Version
School of Computer Science & Engineering
University of New South Wales

 Advanced Operating Systems 
 COMP9242 2014/S2 

Project: A Simple Operating System

These pages outline what you will be expected to implement for the project. While some minor details may change during session, this has been a successful format for a number of years. It is a good idea to start thinking early and try to understand the full assignment and ask any questions you have about structure and problems early.


The aim of the assignment is to implement a simple operating system (SOS) server on top of the seL4 microkernel. The SOS server is expected to provide a specified system call interface to its clients (Specified in libs/libsos/include/sos.h).

The project will be completed by groups of 2 students. This is a challenging project. You have been warned! The project is to be completed using the facilities in the Sabre Lite Lab.


About half the marks for the project are obtained for timely and complete submission and demonstration of intermediate milestones (M0–M8). These milestones will be demonstrated in the lab each week. When demonstrating your solution you should be able to

The remaining marks will be determined by our assessment of your overall project and documentation. The assessment involves:


All milestones must be submitted via give and are due at 12:00 pm, Tuesday (i.e. midday) of the respective week! The demonstrations of what was submitted must be completed in the same week. Details of how to submit can be found here

M0: Familiarisation
Due: Week 2
Marks: 4 (-1 for one week late, discontinue course if more than one week late)
Milestone 0 involves familiarising yourself with the provided source code and build system, and then writing a simple IPC protocol. This milestone should be done individually. Further milestones are done in groups.
M1: A timer driver
Due: Week 3
Marks: 4 (-1 per week late, discontinue course if more than one week late)
Write a simple device driver for the timers available on the i.MX6.
M2: Memory manager
Due: Week 4
Marks: 4
Design and implement a simple frame table.
M3: A pager
Due: Week 5
Marks: 4 (-1 per week late)
Design and implement a simple pager based on the existing pager and the memory manager completed in M2.
M4: System call interface
Due: Week 6
Marks: 4 (-1 per week late)
Design and implement the system call interface for your operating system.
M5: Implement filesystem
Due: Week 7
Marks: 4 (-1 per week late)
Using the provided code implement the filesystem related system calls. Use your timer driver to benchmark your implementation.
M6: Demand paging
Due: Week 9
Marks: 4 (-1 per week late)
Implement demand paging in your operating system.
M7: Process management
Due: Week 10
Marks: 4 (-1 per week late)
Design and implement process management. You should implement the process_* system calls.
M8: ELF Loading
Due: Week 11
Marks: 4 (-1 per week late)
Extend your process management code to handle loading ELF files. This is your last demo; your entire system should be working at this stage.
M9: Documentation and final system
Due: Week 12, Tuesday 12:00 (midday), 21 Oct.
Marks: 9 (-2 per week late) docs, 20 (-3 per week late) code
Complete the documentation for your project. You also have a chance to clean up your codebase for your final submission. This milestone does not involve a lab demo.

Advanced Components (aka Stuff for Masochists)

The following features, if demonstrated and submitted together with your Milestone 8, will give bonus marks. (2 marks each, -1 per week late.)

Shared memory
Implement shared memory via the share_vm() system call and demonstrate operation with some application which has processes communicating via shared memory.
mmap and munmap
Implement the mmap() and munmap() system calls to allow malloc() and free() to support dynamic allocations greater than 112KiB.
Clock driver loaded from file system
Rather than loading your clock driver from the boot image, load it from the file system and run it as a separate seL4 task.
Filesystem caching
Reserve a part of RAM as a file system cache. Implement caching of directory information and file data, as well as read-ahead, to improve file system performance.
Dynamic filesystem (only valid with file system caching)
Have your SOS file system behave correctly even if files are added/removed in the Unix file system while your SOS is running. Do this without significantly degrading performance.
Kernel bugs
Note that your kernel is not verified, although it shares most of the code with the verified kernel. As such, it is highly unlikely that you trigger a bug. Should you be able to demonstrate a (not yet known) bug, you'll also get bonus marks, but the bug must be confirmed by a developer.

If you find a bug in the verified code you'll get a lifelong supply of beer at Gerwin's expense ;-)

Notes on Bonus Marks



Some students are tempted to write some tricky or obscure code for these projects. Other students run into problems by trying to do too much.

I can only reiterate that the debugging environment you have on the Sabre Lite is extremely spartan. You will not do yourself a favour by writing obscure or particularly tricky code. You'll most likely end up getting hoplessly tangled up in your own code. Don't do this.

Write your code as clearly, obviously and straightforward as possible. This is the best safeguard against obscure bugs. I believe that the project is challenging enough as it is, there is no need to make it harder.

Furthermore, when doing the final project marking I will obviously not look with much sympathy upon code I find difficult to understand.

The same applies for implementing features beyond the project specifications. You are welcome to do this, but, in your own interest, you are strongly advised to implement the required features first. First make it work, then go for the extras! Most of the (very few) students who have failed the course to date have ignored this rule — at their peril!

Demonstration and Submission of Milestones

You are required to submit a patch file (a diff) of all your code for the current and preceding milestones via give.

Additionally, you are to show that your project passes the milestone requirements by demonstrating its operation to a demonstrator during one of the allocated times during the week the milestone is due!.

You can only demonstrate what you submitted via give!. You are not allowed to fix any bugs found after the deadline for that weeks demonstration.

For each milestone (except milestone 9), we require you submit a diff of your code from the initial state of the code. See our submission guidelines for details.

For milestone 9, we require you submit your documentation and your code diff to m9doc and m9code respectively.

give cs9242 m9doc documentation.pdf
give cs9242 m9code m9.diff

Only one member of the group needs to submit.


Last modified: 20 Oct 2014.