[an error occurred while processing this directive]
Project: Administrative Details
The practical component of this course consist of a simple initial
exercise and one large project. The below milestones indicate when
certain parts are to be delivered.
Note: Before starting on any
assignment work first study the ASysT Lab page
and build and run the hello-world program linked to that page. Do not try to go further until you have done
this!
The initial exercise (``milestone 0'') is a
``warm-up'' designed to get you into the swing of L4. It is due in
week 2 and timely demonstration will be worth 4 marks. Further
milestones constitute parts of the project. Milestone 0 is best
done individually, but I will allow demonstrations individually as well
as by groups.
Project
The other milestones constitute the major project SOS: A Simple Operating System.
The project is to be done in groups of two.
You will need explicit
approval from the LiC for any other group size. Try to get your group
organised. Contact me if
you have not found a partner by the end of Week 3.
Almost half of the marks obtainable by project work can be obtained for
timely and complete demonstration of the intermediate milestones. The
remaining marks will be determined by our assessment of your project and
documentation. The assessment involves:
- testing your code and its conformance with 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.
The due dates of the various milestones are:
- Week 3: Milestone 0  (4 marks, minus 1 per week late).
- Week 4: Milestone 1  (4 marks, minus 1 per
week late).
- Week 5: Milestone 2  (4 marks, minus 1 per
week late).
- Week 6: Milestone 3  (4 marks, minus 1 per
week late).
- Week 7: Milestone 4  (4 marks, minus 1 per
week late).
- Week 8: Milestone 5  (4 marks, minus 1 per
week late).
- Week 9: Milestone 6  (4 marks, minus 1 per
week late).
- Week 10: Milestone 7 (4 marks, minus 1 per week
late).
- Week 11: Milestone 8 (25 marks, minus 6 per week
late).
- Week 11: Shared Memory
Bonus (optional, 2 marks, minus 1 per week late).
- Week 11: Clock Driver
Bonus (optional, 2 marks, minus 1 per week late).
- Week 11: File System
Caching Bonus (optional, 2 marks, minus 1 per week late).
- Week 11: Dynamic File System
Bonus (optional, 2 marks, minus 1 per week late).
- Week 11: OS Paging
Bonus (optional, 2 marks, minus 1 per week late).
- Week 11: NFS
Bonus (optional, 2 marks, minus 1 per week late).
- Week 12: Final
Milestone (8 marks, minus 2 per week late).
Mid-session break arrangements: As far as milestone demonstrations and
submissions are concerned, the mid-session break is considered
non-existent. For example, demonstrating Milestone 6 in Week 10 will cost you
one mark.
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.
- Bonus marks can also be obtained by finding bugs in L4: The
first student who proves an as-yet-unkonwn bug in our L4
implementation will receive two bonus marks. This bonus only
applies to L4 kernel bugs, not library bugs. Any student who
fixes an L4 kernel bug will also receive two bonus
marks.
- The maximum number of bonus marks that can be accumulated is
10, no matter how they have been earned.
- Bonus marks (for L4 bugs or 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!
Problems?
If you have problems you should first check:
Make sure you check these first before asking us. We'll send you
straight back to do your homework if you ask questions which are already
answered there!
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
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, i.e.:
give cs9242 m0 file1.c file2.c ...
substituting m0 for the actual milestone number.
You should submit all your code, including makefiles etc. If you
need to submit a tree of files (i.e. your OS source has subdirectories)
you may submit a tar file. To create a tar file, cd to the directory
above your source tree and type, for example,
tar cvf cs9242-m0.tar OS
This creates a tar file named cs9242-m0.tar containing
the directory OS (you may have different names, of course).
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 6 are awarded at demonstration
time. Marks for milestones 7, 8 (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 7 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 8, 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:
20 Aug 2002.
[an error occurred while processing this directive]