School of Computer Science & Engineering
University of New South Wales
Advanced Operating Systems
COMP9242 2003/S2
Project: A Simple Operating System
- Overview
- Assessment
- Milestones
- Resources
- A warning
- Demonstrations
The aim of the assignment is to implement a Simple Operating
System (SOS) server on top of the L4 micro-kernel. 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 ASysT Lab.
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. 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.
- M0: Familiarisation
-
Due: Week 3
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
mileston should be done individually. Further milestones are
done in groups.
- M1: Memory manager
-
Due: Week 4
Marks: 4 (-1 per week late)
Design and implement a simple frame table.
- M2: 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 M1.
- M3: System call interface
-
Due: Week 6
Marks: 4 (-1 per week late)
Design and implement the system call interface for your
operating system.
- M4: A clock driver
-
Due: Week 7
Marks: 4 (-1 per week late)
Write a simple device driver for the timer functions
available on the GT chip.
- M5: Implement filesystem
-
Due: Week 8
Marks: 4 (-1 per week late)
Using the provided code implement the filesystem related
system calls.
- M6: Demand paging
-
Due: Week 10
Marks: 4 (-1 per week late)
Implement the demand paging in your operating system.
- M7: Process management
-
Due: Week 11
Marks: 4 (-1 per week late)
Design and implement process management. You should
implement the process_*
system calls.
- M8: ELF Loading
-
Due: Week 12
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 13
Marks: 9 (-2 per week late)
Complete the documentation for your project.
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.
- Clocked 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.
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
U4600s is extremely spartanic. 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! The only students
who have failed the course to date have ignored this rule
—
at their
peril!
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 using the give
system.
You should submit all your code, including makefiles
etc. This means that you should create a tar file of your
submission. eg:
tar cvf cs9242-m0.tar.gz sos
give cs9242 m0 cs9242-m0.tar.gz
Only one member of the group needs to submit.
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.
- Milestones 1-2 will be handled similarly as we want to make
sure you're on the right track and point out mistakes in the
code. These are essentially code inspections.
- 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 8 are awarded at demonstration
time. Marks for milestones 9, 10 (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). We will specify in time a Makefile
fragment (which will be part of your submission) which describes
the set of files to compile and link to get your OS up and run
our own testing shell. The same holds for submissions competing
for bonus marks.
- 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 definitively not a word document or anything the
like).
- Final code submission
guidelines
Last modified:
05 Nov 2003.