Personal tools

Advanced Operating Systems Project: A Simple Operating System

The project for this course is based heavily on the project from COMP9242 at The University of New South Wales. You may find further useful information and resources in the COMP9242 website, but in all cases the specification and other information provided here is considered authoritative.

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 at UNSW 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.

  1. Overview
  2. Assessment
  3. Milestones
  4. Resources
  5. A warning
  6. Demonstrations

Overview

The aim of the assignment is to implement a simple operating system (SOS) server on top of the L4 microkernel. The SOS server is expected provide a specified system call interface to its clients. (Specified in 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 Slug Lab.

Assessment

More than half the marks for the project are obtained for timely and complete demonstration of intermediate milestones. These milestones will be demonstrated in the lab each week.

Milestone deadlines missed by no more than one week will cause a loss of 25% of the mark for that particular milestone, if missed by more that one week the penalty is 50%, up to a maximum of two weeks. No submissions/demos will be accepted later than two weeks after the deadline. Furthermore, students who have difficulty completing the first two milestones (m0 and m1) are advised to consider changing courses.

When demonstrating your solution you should be able to

  • show a working solution,
  • explain how to code you have written works, and
  • explain any design decisions you made.

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

  • testing your code and its conformance with the specifications,
  • inspecting your code as to how well and efficiently it is written, and
  • perusing your documentation as to its completeness, appropriateness and consistency with your implementation.

Milestones

M0: Familiarisation
Due: Week 3 (07.03.08)
Marks: 4 (-1 per 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: Memory manager
Due: Week 4 (14.03.08)
Marks: 4 (-1 per week late)
Design and implement a simple frame table.
M2: A pager
Due: Week 7 (Different day: Tuesday 01.04.08)
Marks: 4 (-1 per week late)
Design and implement a simple pager based on the existing pager and the memory manager completed in M1.
M3: System call interface
Due: Week 8 (11.04.08)
Marks: 4 (-1 per week late)
Design and implement the system call interface for your operating system.
M4: Implement filesystem
Due: Week 9 (18.04.08)
Marks: 4 (-1 per week late)
Using the provided code implement the filesystem related system calls.
M5: A timer driver and benchmarking
Due: Week 10 (25.04.08)
Marks: 4 (-1 per week late)
Write a simple device driver for the timer functions available on the IXP420's Timers. And use it to benchmark your filesystem.
M6: Demand paging
Due: Week 12 (09.05.08)
Marks: 4 (-1 per week late)
Implement the demand paging in your operating system.
M7: Process management
Due: Week 13 (16.05.08)
Marks: 4 (-1 per week late)
Design and implement process management. You should implement the process_* system calls.
M8: ELF Loading
Due: Week 14 (23.05.08)
Marks: 24 (-4 per week late)
Extend your process management code to handle loading ELF files. This is your final milestone, and you should be prepared to demonstrate you entire system working at this stage.
M9: Documentation
Due: Week 15 (30.05.08)
Marks: 9 (-2 per week late)
Complete the documentation for your project.

Advanced Components (aka Stuff for Masochists)

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

Shared memory
Implement the shared memory via the share_vm() system call and demonstrate operation with some application which has processes communicating via shared memory.
Clock driver loaded from file system
Rather than loading your clock driver from the boot imager, load it from the file system and run it as a separate L4 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.

Resources

Warning!

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.

We can only reiterate that the debugging environment you have on the Slug 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. We 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 we will obviously not look with much sympathy upon code we 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 at UNSW have ignored this rule — at their peril!

Demonstration and Submission of Milestones

Your are to show that your project passes the milestone requirements by demonstrating its operation to the demonstrator during the allocated time during the week the milestone is due.

In addition, you are to submit your source code for each milestone.

You should submit all your code, including makefiles etc. This means that you should create a tar file of your submission. eg:

tar cvzf aos-m0.tar.gz aos_project

Once you have created your tar file, you should submit it online here. Only one member of each group needs to submit, except for Milestone zero where students have worked individually.

Notes

  • All students belonging to the group must be present during the demonstration.
  • Only one group member needs to submit the source code electronically.
  • The demonstrator will ask you questions on your implementation to make sure that you understand what you are presenting. Your responses to this questioning will have a major impact on the mark you will be receiving.
    Zero marks will be awarded if you cannot demonstrate a basic understanding of your solution. A trial-and-error approach will not get you anywhere.
  • In most cases all members of a group will receive the same mark. However, in cases where there is a clear difference in understanding of the problem and its solution between the group members, we will differentiate the marks awarded.
  • Milestone 0 is mainly intended to ensure that you understand the basics, and generally students are asked to improve their code rather than docking off marks.
  • This is different for the later milestones, which serve to ensure that you have met the specified target. Marks will be deducted for incomplete or faulty implementations. In these milestones we will not look at your code but only check that you seem to have have implemented the requested functionality. It is up to you to supply a driver program which demonstrates this.
  • Marks for milestones 0 to 7 are awarded at demonstration time. Marks for milestones 8, 9 (and potential bonus) are only awarded after our testing and code inspection. However, you will still have to do the demonstration. This is to avoid problems with obviously incomplete or non-compliant code.
  • Milestone 8, besides demonstrating the functionality, will require you to submit the full code in a form we can use for automatic testing. This means that you will have removed all debugging output, none of your OS or library code should write anything (other than what clients write to the console).
    Update (20.05.2008): due to an inconsistency in an earlier version of this page, the final source code for the complete system including any bonus components may be submitted up to 30.05.2008 without a late penalty. This will be used to determine your marks for milestone 8. You will still be expected to demonstrate your complete system in week 14 (23.05.2008). All source code should be submitted under the milestone 8 category in the submission system. Milestone 9 is to be used only for the documentation (which is now due on the same day).
  • For Milestone 9, the documentation, will be submitted in hardcopy as well as electronically as a ASCII text file (with or without TeX or troff formatting commands, but definitely not a Word document or anything the like).
Document Actions