Grading
Passing the course requires that you reasonably participate in project team work. If you do, passing automated tests for all baseline features guarantees passing the course. The exact grade depends on bonus points:
-
If you submit an implementation that passes the automated tests on milestone schedule, rather than only by the end of the course, you will receive 2 bonus points for each such milestone. We require that the team work contributor form, outlined below, is also completed before the deadline. Only members that complete this form are eligible for the bonus points.
-
If you submit an implementation that passes the automated tests for an optional feature by the end of the course, you will receive bonus points for that feature. The exact number of bonus points is listed in the feature specification below and reflects the feature complexity, typically 10-20 bonus points can be collected by implementing all optional features of a milestone.
-
Your implementation will undergo code review at the end of the course. In the code review, we will deduce bonus points for poor code quality. We will also request corrections in case any of the features is broken and the tests pass only accidentally.
-
A penalty of 3 bonus points will be deducted for every window of three consecutive weeks where you have failed more than one quiz. A quiz is considered failed if you did not make a reasonable attempt at answering any question. Windows crossing the semester boundary also count.
Collecting at least 50 bonus points will earn you the excellent grade. Collecting at least 30 bonus points will earn you the very good grade. Less than that will leave you with the good grade.
Team Work
We expect the team members to communicate with each other frequently to ensure that your project is moving forward. We also expect reasonable work distribution - while it is not necessary that each team member performs equally, we require that each team member contributes (with code, debugging, documentation, and so on) to all baseline features of all milestones. Contribution to optional features is likewise optional, however, bonus points for optional features are only collected by those team members that contributed to those features.
To assess individual contribution, we require that each team member updates their own team work contributor form with each feature submission. We urge you to communicate with us early if team work distribution becomes an issue. We reserve the right to adjust grading or even team composition to resolve such issues.
Please note that we try to keep the grading information compact and avoid legalese, however, we will penalize attempts at gaming the system through formalistic interpretation.
Implementation Grading Details
Each implementation must pass the baseline milestone tests that provide core functions of your kernels. A working baseline implementation of all the previous milestones is also needed for subsequent milestones as they extend the existing implementation with new features.
For each milestone we provide a set of optional extended features that you can implement to improve your knowledge and skills (and get a better grade too :-).
The table below lists the optional features together with their bonus points, which roughly reflect the complexity of each assignment. Automated tests exist for most of the optional features, however, we will also check the implementation manually.
Some of the features are additive and require prior implementation of another
feature (for example, the implementation of mutex_try_lock requires a working
implementation of mutexes, the bonus points thus reflect the amount of work
needed for adding a single function to a working mutex implementation).
| Milestone | Points | Feature |
|---|---|---|
| M01 | Dive into kernel | |
| 1 | Implementation of debug_dump_function |
|
| M02 | Kernel heap management | |
| 4 | Implementation of kfree |
|
| 7 | kfree with coalescing of free blocks |
|
| M03 | Threads and cooperative scheduler | |
| 7 | No leaks for thread_join and thread_kill (requires manual checks) |
|
| 2 | Support for thread return values and parameters | |
| M04 | Preemptive scheduler and synchronization | |
| 1 | Fair thread scheduling | |
| 4 | Support for mutexes (with passive waiting) | |
| 1 | Implementation of mutex_try_lock |
|
| 6 | Support for semaphores (with passive waiting) | |
| 1 | Implementation of sem_try_lock |
|
| M05 | Frame allocator and virtual memory support | |
| 2 | Implementation of frame_free |
|
| 5 | No leaks in address space and thread implementation (requires manual checks) | |
| 3 | On-demand page allocation | |
| 2 | Dynamically allocated bitmap of free frames | |
| 4 | Dynamically growing heap on top of frame allocator (requires manual checks) | |
| 4 | Up to 255 address spaces | |
| 6 | Up to 255 concurrently existing address spaces | |
| 6 | No limit on amount of existing address spaces | |
| M06 | User process support | |
| 4 | Support for (userspace) printf |
|
| 5 | Buffering implementation of printf (no automated tests) |
|
| 7 | Support for procinfo system call |
|
| 4 | Support for userspace heap |
All work must be submitted before the final deadline (mid January, see our calendar.
When the NSWI200 Midterm Survey is filled-in before deadline (November 14th), four bonus points are awarded.
When the NSWI200 Christmas Survey is filled-in before deadline (Jan 9th), four bonus points are awarded.