due 01/16/2018 at 5:00PM
For this assignment, you can choose one project from the list below. The grading will depend on the correctness and thoroughness of your implementation. Any of the projects can get you full credit if you prove to us that you researched the subject thoroughly and did a substantial amount of coding.
This assignment is to be completed individually: you may reuse earlier code created with a partner as a starting point, but the project itself should be your own work.
There will be no design review for this project. Instead you should submit a report detailing what you've implemented, the research you performed, and a brief description of the code you've written. If what you are describing is best explained with a diagram, please create one (or more). The document should be in PDF format, and be titled README.pdf. Please limit your document to 5 pages.
When you are finished, tar the directory containing your
code and README.pdf file, and submit it to Dropbox.
Change the bootloader to switch the video mode to a graphic mode. Implement text output (in the console driver) by having a font built in the kernel (as a simple array of bytes).
Expose the VGA memory through a memory mapping, add system calls to turn on and off a "video" mode inside the kernel. When video mode is enabled, map the VGA buffer into userspace. Your driver should support at least 4 colors and a resolution of 640x480.
Implement a little user program that does cool things in video mode. For example, write a user program to display a screensaver application or any other interesting animation, and add some control to allow the user to interact with the program with keyboard inputs.
Useful links:
The shell of the previous assignment is only a mock of a real UNIX shell. This project makes it a lot more interesting and has you go down the same design decisions UNIX creators went through.
Unify console IO, IPC, and FS read/writes.
Create a new kernel abstraction of "file descriptor" (represent them in userspace as integers). Two special file descriptors are the console input and the console output. Other file descriptors can either be a pipe between two processes, a write sink to a file, or a read source from a file.
Add a new system call to create a file descriptor in one of the 3 modes above. Have the kernel initialize the console in and console out file descriptors.
Once you have your new abstraction, remove the readline, puts,
produce, and consume system calls. They are now functionally
subsumed by two new system calls read and write that read
from the input channel and write to the output channel of the
process.
The input/output channels of a process are specified in extra arguments you will add to spawn, the shell is started with the console in and console out channels.
Finally, make the shell able to parse redirections from and to files and other processes. Demonstrate the full functionality of your new shell with pipelines like:
- cat file | rot13 > file.encrypted
Read on the guts of debuggers, then implement a system call API to have a debugging mechanism. Your debugger process should be able to spawn another process, place a few breakpoints in it, dump some interesting memory contents while the debuggee is stopped, and resume the execution.
Your debugger will run in 3 phases:
start command).
dump 0x12345678) or resume the execution
(continue).
Give us a sample run in the README together with an explanation as to why it is interesting.
Read the literature on dynamic priority-based schedulers. Implement one and showcase its new scheduling features on an example with multiple processes running.
Your new scheduler also needs to implement a load balancing mechanism to make sure that all the CPUs of the computer are fully utilized.
Detail your scheduling algorithm extensively in the README, and justify your comments by providing comprehensive benchmark results. Your scheduler implementation should be cache efficient. Do some research on the multi-core cache hierarchy models and illustrate clearly how each of your design decisions impacts the cache performance. Back up your claim with concrete benchmarks.
You can study the Plan 9 scheduler as a starting point.
Study how qemu supports the audio, then enable appropriate audio devices in qemu, and implement related drivers. Then expose a reasonable API to the user level so that user programs can manipulate the sound, and implement some interesting user applications. For example, you can implement a simple piano application with limited notes, and then implement another application to play a self-composed song with provided notes. Make sure that the sound is of reasonable quality. Try to decode and play an audio file stored in the hard disk. You can use some open source decoders if you like.
We encourage you to choose one of the projects listed above. However, if you have another idea that is interesting to you, and seems to be of a similar scope as the recommended ones, feel free to contact one of the TAs about it, and we will determine whether it will suffice.