Project 2: Infokernel
Due: Wed 3/26
The project is one to get you a little more deeply involved with various aspects of the Linux kernel. You'll start by reading a paper, and then continue by doing some of the things the paper hints at and suggests.
Unlike the previous project, you can work with one partner for this one.
Part 1: Read the infokernel Paper
Some years back, we worked on a new idea in OS design known as the infokernel. Read the paper here.
As you'll see in the paper, the infokernel advocates exposing many details within the OS that are often hidden. For example, why not expose which physical pages various virtual pages are mapped to? If a process can make use of that information, it might be worthwhile.
Part 2: Informed VM
In the first part of this project, you'll open up the VM system just a bit by implementing a new system call: int vm_mapinfo(unsigned int va, unsigned int *pfn). This call will take one input argument: a virtual address within the calling process (assume we're using a 32-bit kernel; hence the VA is 32 bits); it also takes another argument, pfn , which is where the PFN for the virtual address will be written (assuming such a translation exists).
Your system call should return 0 upon success; -1 if the virtual address is not mapped; and finally it should return 1 if the page is not present. In the first case (return code = 0), the pfn argument should be filled in with the page frame number (PFN) where this virtual page containing va resides. In the other two cases, the contents of pfn after the call are undefined.
You should build a little test suite that checks whether your system call works. The tricky part is figuring out how to walk the page table while grabbing the correct locks; look in the mm/ directory for plenty of examples of code that does this sort of thing in the kernel. And, of course, poke around the internet for more documentation; Linux Kernel books are always a good source of information.
Part 3: Informed File System
In this part of the project, you'll expose some of the internals of the Linux ext2 file system. Specifically, you'll implement a simple call that reveals the on-disk location of a block of a file or directory.
The call you'll implement is fs_mapinfo(int fd, unsigned int offset, unsigned int *block). This call takes an offset in a given (previously opened) file and, if successful, fills in the second parameter - block - with the disk block that the file resides in. The call should work for both files and directories, and return an error for any other type of file.
The return codes for the call are 0 upon success; -1 if the offset is not part of the file; 1 if the offset is part of the file but not yet mapped (i.e., the file has holes).
Once again, you should build a little test suite to show how your code works. Most of the code you'll care about is in the fs/ext2 directory.
Part 4: Your Time To Shine
To add a little creativity, in the last part of the project, you'll get to decide on some cool thing to expose within the kernel and build that. Some possible ideas: anything related to the CPU scheduler; the ability to track the status of an I/O as it is read or written; more detailed VM information, including aspects related to replacement; and so forth. Any idea can be explored; the better the idea, the better you'll do on this part of the project.
Handing It In
To turn this in, you will create a screencast demo of what you have done. Show demos of the pieces you've built, and the code you wrote. The screencast should be something I can view easily on a Mac, i.e., Quicktime. The screencast should also be short: less than 5 minutes or so.
Copy the screencast into your handin directory:
You should also copy relevant files that you have changed into the handin directory, but please not the entire kernel!
Please also include a README file. In there, describe what you did a little bit. The most important bit, at the top, however, should be the authorship of the project, including who your partner is. Put the code and all the stuff mentioned above in one person's directory; put a symbolic link from the other person's handin directory for p2 to the place where the code is handed in.