[an error occurred while processing this directive]
School of Computer Science & Engineering
University of New South Wales
Advanced Operating Systems
COMP9242 2015/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.
Overview
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.
Assessment
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
- show a working solution,
- explain how the 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
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
- No bonus marks will be awarded on a
“sympathy” basis for a
well-intended attempt — your code implementing a bonus feature must
completely work (except for maybe some minor details) in order
to qualify for a bonus.
- The maximum number of bonus marks that can be accumulated is
10, no matter how they have been earned.
- Bonus marks (for doing a bonus component of the
project) can be used to make up for lost project marks,
up to the maximum project mark possible (65). If your total
project marks, including bonus, exceeds 65, the surplus can be
used at half face value for marks lost in the exam.
- Bonus marks cannot be used if the raw exam mark is less
than 40%, a 40% raw exam mark is an absolute prerequisite
for passing the course!
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.
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.
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 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 milestone 9 (and potential bonus) are only
awarded after our testing and code inspection.
- Milestone 9
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).
- Milestone 9, the
documentation, will be submitted electronically as a PDF
file. We also tolerate ASCII text files (with or without LaTeX
or HTML formatting commands), but definitively not a
word/ODF/XML document or anything the like).
Last modified:
05 Aug 2015.
[an error occurred while processing this directive]