For the project, the goal is to add more functionality to your PintOS such that more and more tests pass when you run
make check in the different directories. The instructions for the project are less detailed than for the lab assignments which means that you may need to spend more time on reading and understanding the PintOS documentation and sources. You should implement three distinct features for the project: read-only executables, priority scheduling and memory-mapped files. You are welcome to implement more features if you wish, but make sure in any case that all previous tests still pass.
After completing the project you will have a deeper understanding of specific OS features such as protection, scheduling with priorities, and memory mapped files. You will also understand better how the different services and features impact each other.
Part 1: Read-Only Executables
Add code to deny writes to files in use as executables. See section 3.3.5 in the PintOS documentation for details. The amount of code you will need to write for this is minimal. Working directory:
src/userprog. Tests to pass (besides all the other tests from the labs and project - your new code should not break those):
tests/userprog/rox-simple tests/userprog/rox-child tests/userprog/rox-multichild
Part 2: Priority Scheduling
Implement priority scheduling in PintOS. See section 2.2.3 in the PintOS documentation for details. For testing, use the
src/threads directory with
make check (the
mlfqs tests will not need to pass for this part). Making sure that threads run according to the given priorities is not that complicated, but getting the inheritance (
priority-donate-* tests) right will require gradual and thorough design.
Following are a few hints to help you towards a possible implementation. You do not have to follow these, you are free to implement your own solutions.
- use a list of held locks in each thread (best if this is kept ordered!)
- introduce a
dictatorvariable for each lock (pointing to the thread that will determine the priority of the lock holder)
- compute the thread priority based on the list of held locks (i.e. the highest priority of the
- careful with possible infinite loops when computing the priority based on these structures
- any time the
dictatorof a lock changes, the list of the held locks of the holder must be re-sorted
priority-donate-lowertest will require you to lower a thread's priority in a delayed manner; save the wanted priority in another variable and update based on this only when nobody else dictates the thread's priority
Note: do not forget to keep checking that the rest of the configurations work.
make check in
src/vm should still work fine! In some cases
sema_up can cause serious failures hard to identify - make sure you only call this if the next thread to execute has higher priority and not during an interrupt context.
Part 3: Memory Mapped Files
See sections 4.1.7 and 4.3.4 in the PintOS documentation for details. Working directory:
src/vm. Tests to pass: all the tests matching
tests/vm/mmap-* as well as
- Motivation for the code added in each of the parts.
- The modified PintOS source code (one version! not three different for each part) that is passing all the
make checktests as specified for each part. Naturally, the tests for the labs should still pass.
- The estimated time needed to complete the project is much less than 80h (expected 4h + 24h + 36h), which would amount to 3 credit points. However, adding the work done for lab 0, will bring up your total to 80h for the project.