Project 4: Optional Final Projects

Assigned Wed. April 23; Due Mon May 19; 100 pts


One of the following three projects may be done instead of taking the final exam. If you want, you can take the exam and do a project; in that case, you will get the higher of the two scores. As before, you can work on your own, or in groups of up to three. The groups do not have to be the same as for project 3, but I need to know who the groups are, and which of the projects they are working on.

The Projects

Each of the following projects is more challenging than any of the first three, but they are by no means intractable, and I have had many other students complete similar projects successfully. You will be on your own to a larger degree than in the first three projects, in that I won't provide as many hints or quite as detailed step-by-step guidance, thought of course I will provide a reasonable amount of help.

For each of the projects, you can either port existing code or write your code from scratch. Because of the greater difficulty, in many cases partial success, or even a very good start, will be enough to get you an "A"; details depend on the specific project.

(a.) A Graphics Driver

Add a basic graphics driver to Minix. (This is exercise 33, from page 308 of your text.)

You can support VGA, Hercules, or any other common graphics format of your choice. The user interface should be through a new device, /dev/graphics. Though features like block copy and graphics primitives would be nice for a "production" driver, for this project you don't have to implement anything beyond setting or unsetting individual pixels. There is a tremendous variability among VGA-family graphics cards, however most cards support a basic 480 x 640 VGA mode. To get started, you can look at drivers for other OS's, including Linux; simple drivers for DOS may be the most helpful.

(b.) A Mouse Driver

Write a basic mouse driver, something like the Linux "gpm" mouse driver, that works with the console in text mode.

This is probably most easily done working with a serial mouse and an existing tty driver. You will need to make some modifications to the screen driver as well. For purposes of evaluating the project, you don't have to implement "drag and drop," and it will be enough if you can get the mouse to move the console cursor. If your mouse doesn't work at all with the screen driver (e.g., if all you can do is move a special character around on the screen, independent of the console driver's actual cursor, the project is worth at most 85 (rather than 100) points.

(c.) Add Swapping to Minix

Add swapping to Minix. (This is exercise 28, from page 400 of your text.)

To add swapping to Minix, you must add a swap process and/or modify the memory manager to copy processes in memory to and from swap space, on disk. The memory manager must be modified to free memory space when a process is swapped out, and to allocate space again when it is swapped back in, similarly to what it does now for process termination and creation. In addition, the swapper needs a scheduler that works in conjunction with the process scheduler; you can't run a process that is swapped out!

Adding fully developed swapping to Minix is a big project. To make this manageable as a class project, you can swap to a single large file, rather than to a special disk partition, and you need not have a fully worked out swapper scheduler; it will be enough if you can demonstrate (e.g., with a special function key) a procedure that forces a specified process to swap in or out.

What to turn in

Each group should turn in a single floppy; this should have a minix filesystem on it, and be mountable. The floppy should be clearly labeled with the group and user names, the project, and if done in the lab, the machine number.

The top level directory of the floppy should contain

  1. Your modified kernel, named "minix",

  2. A tar file, "mods.tar" of just those kernel sources you modified to build your new kernel, and

  3. A "README" file, with the group name and group members names and SSN's. This file should include a detailed description of your project, including information about limitations, restrictions, or special conditions under which it should be tested.

Grading

Working correctly counts for 80% of your grade, documentation (as comments in your modifications) counts for 10%, and the project description in the README file counts for 10%. In addition, if you are working in the labs, you can loose points, either individually or as a group, for not following the lab procedures, as described below.

Since you will need to turn in a floppy disk rather than using the submit program, the rules for early and late projects are slightly different from those described in the "General Information About Projects." The project is due Monday the 19th, by 6:00 pm. If you turn in your project the previous Friday the 16th, by 6:00 pm, you get a 10% bonus; if you turn it in after Monday the 19th at 6:00, you get a 10% penalty. The semester ends on the 20th, and I can't take projects after that date.

Using the Lab

The 311, 411, and circuits students have precedence in the lab. We should have it largely to ourselves before and after class, and Tuesdays and Thursdays after about 4:00. The TA Changgong Zhang has a key, and you can make arrangements with either him or myself to get in at other times.

Because the lab is shared among so many users, and our own section is so large, it is very important that some basic rules are followed:

Students may be penalized up to the full points possible for a project, either individually (if culprits can be determined) or as a group, for not following the above rules.

Hints and Suggestions

It is strongly recommended (though not required) that you work as "bin" rather than as "root" when modifying the kernel; this give you a little extra protection, and the system is set up to allow "bin" to recompile and run the new kernel.

A typical development cycle will go something as follows

  1. Study the relevant kernel sources
  2. Modify selected code and headers in /usr/src/kernel
  3. "make" (in /usr/src/kernel, to rebuild the kernel)
  4. goto 1 if the compilation was unsuccessful
  5. "cd /usr/src/tools"
  6. "make fdboot" (to make a boot floppy)
  7. "shutdown" (to exit Minix)
  8. "exit" (to exit the boot monitor)
  9. The system reboots with the new kernel
  10. Test things carefully
  11. goto 1, as necessary
  12. Make a tar file "mods.tar" of the kernel files you've modified
  13. Write up your "README" file
  14. Copy the tar file and README to your floppy.

Note that the "make fdboot" command makes a mountable (and bootable) floppy with a "minix" image on it for you; but you'll still have to mount this by hand, to copy the README and tar file to it.