Final Project

Important deadlines

• Project proposal due 3/1 (Tuesday) at 9:00pm (submit on Gradescope
• Project implementation due 3/16 (Wednesday) at 9:00pm (submit on Gradescope)—this is the last day of exams, no late days can be used

Overview

For this lab, you will pick a project of your choice to extend osv. We encourage you to take this time to explore particular OS features that you find interesting. I have provided a list of project ideas for reference. You can pick one from the list or do anything else you wish.

For project proposal, follow the template. Here is a sample proposal.

Some general places to look for helpful resources to research your project topic:

• Documentation on other educational kernels: xv6, Pintos
• Documentation on the Linux kernel (i.e., look up how the Linux kernel does it)
• The OSDev wiki
• Online Linux man pages

Potential projects

User threading library

• Allow applications to run many user threads on top of its kernel thread.
• To add user library files, create them under lib/ and start your file with prefix u, so that the Makefile can link them only to user processes. For example, you can create lib/uthreads.c, lib/usched.c and so on.

Kernel threading library

• Expose kernel thread interface to user applications, allows an application to create multiple kernel threads.
• Requires adding system calls and letting a process to create kernel threads, let a kernel thread exit, and allow a kernel thread in the process to join another thread (wait for another thread to terminate).
• Once a process can have multiple kernel threads, it is necessary to re-examine kernel/syscall.c and kernel/proc.c to make sure they are safe in the new multithreaded process setting.

Named shared memory

• Add system calls to allow processes to create, map, and unmap a shared memory region.
• Processes should be able to create a shared memory region with a given name and size.
• Once a named shared memory is created, other processes can address the shared memory region by name, and map it into its own address space with a particular permission and unmap it from its address space.
• This is functionally similar to pipe, but communication through shared memory does not go through the kernel once the memory is mapped into processes’ address spaces.

Signals

• A way for processes to send software interrupt to another process through the kernel.
• Define a set of signals to support, provide a default set of signal handlers, and add system calls for a process to register their own signal handler with a specific signal.
• A process can send a signal to another process (signal(signal number, pid)), which should cause the signaled process to run the corresponding signal handler.

Priority Scheduling

• Implement a priority based scheduler.
• Detailed priority scheduling description from a different educational OS can be found here section 2.2.3 Priority Scheduling.

Swap

• When kernel runs out of physical pages while handling a user page fault, currently we just exit the process. This is not always desirable. Instead, you can make a physical page available by evicting an in-use physical page (clear its page table mapping, and write it to disk), and give it to the faulting process.
• When the evicted page is accessed later, you need to find its data, write it back to a physical page (if there is no available physical page, you need to evict again), and map it, so that user can still access its memory.
• OSTEP textbook Chapter 21

Additional useful system calls

• Implement any useful system calls you like in osv, a minimum of 5.
• Newly added system calls must be nontrivial: providing a non-cow fork is trivial.
• If you are unsure about whether a system call is too trivial, send me an email.

Testing and Documentation

After implementing your proposed project, you need to create at least five tests under a user/final folder to test your project. The tests should each be distinctive and cover normal use, edge cases, and error handling. You can look at the lab tests for guidance. Each test should run pass(test-name) on success.

In addition to test cases, your submission should include a README text file in the top-level directory. This file should serve as a guide to your implementation, and include the following information

• The features from your proposal that you successfully implemented
• Any non-functional features you attempted to implement
• The files you added or modified, and how they relate to the features above
• What aspects of the implementation each test case tests
• Any features or edge cases the test cases do not address
• Any known bugs
• Anything interesting you would like to share

The README does not replace appropriate documentation in the code itself.

Grading

The final project will be graded out of 160 points as shown in the table below. Poor coding style can lose points, so make sure to submit clean, well-organized code.