Project 3: Minix Message Counting
Assigned Mon March 31; Due Wed April 16; 60 pts
Project Goals
The goals of this project are to learn more about message passing
and Minix internals, and to learn how to modify and test a new
kernel.
The Project
You are to modify the Minix kernel to keep track of the number of
messages sent from process (or task) i to process (or task) j, and
to print this array when the "F4" key is pressed. (This is
exercise 38, from p 152 of your text.) Rows of this array should
correspond to message sources, and columns to message destinations.
Rows and columns should be labeled with process IDs, and rows with
process names, or at least the first few letters of process names.
An example dump from such a kernel modification is available.
With a bit of care, an entire table for all system tasks and a small
number of processes can fit on one screen. Don't overfill the
screen; it's better to simply truncate the processes displayed than
to run things over into an unreadable munge. The example message dump used printf's "%4d" for
most processes, and "%5d" for the processes sending a lot of
messages. It would be better still to display only "interesting"
processes, i.e., processes that have actually sent or recieved some
messages; this is worth a 5% bonus.
As a precaution, you should print your group's name in the header
line of the message dump.
Project Groups
If you have installed Minix on your own machine(s) you can work
either individually or in groups of up to three on your machines.
Students working in the circuits lab (room 237) should form groups
of three. There are not enough machines for smaller groups. You
can form different groups for each project, if desired, but once
group assignments are made, they are fixed for the duration of a
project. Students who haven't formed a group will be assigned to
one.
Each group will be assigned a machine, and will be responsible for
the system administration of that machine. Each group should give
themselves a name, and should should create accounts for their
members, or at the very least least change the root and bin
passwords on their own machines. Do not use another group's
machine. If something seems to be wrong with your machine (in
particular, with the hardware) ask the instructor or TA for help.
Minix can be started on the lab machines with the bootstrap disks
kept in the back cabinet, but it would be a good idea to make your
own bootstrap disk. The bootstrap disks in the lab are set to boot
(as I recall) from /dev/hd2a and /dev/hd2c, so (unless someone has
futzed with them) you should not have to set any system parameters
to boot from them.
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, and machine number.
The top level directory of the floppy should contain
- Your new kernel, named "minix",
- A tar file, "mods.tar" of just those kernel sources you modified
to build your new kernel, and
- A "README" file, with the group name and group members names and
SSN's. This file should include a short paragraph describing how
well your project works, including any limitations, restrictions, or
special conditions.
The floppy, if created by "make fdboot" in the tools directory, may
also contain a boot file and /dev/ directory. See the hints and
suggestions the end of this document.
Grading
Working correctly counts for 80% of your grade, documentation (as
comments in your modifications) counts for 10%, and a correct
analysis of your kernel's functionality in the README file counts
for 10%. In addition, 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 Wednesday by 6:30 pm. If you turn in
your project Monday by 6:30 pm, you get a 10% bonus; if you turn it
in after Wednesday 6:30 but before next Monday at 6:30 there is a
15% penalty; and in general, if we say a "checkpoint" is 6:30 pm on
days the class meets, then there is a 15% penalty for each
checkpoint you miss.
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:
- The 311, 411, and circuits students have precedence in the lab
- Use only the machine assigned to you; in particular do not use
another group's machine. If possible, I will try to keep a spare
machine available for emergencies
- For those machines used to run Windows for the circuits lab,
reboot the machine and restart windows when you are done with it
- Restore the kernel sources and binary to something resembling
their original state when you leave your machine; in particular,
don't leave your modifications around as temptations for others
- No food or drinks in the lab, and in general, clean up any
messes you make
- The last person to leave the lab should make sure the door is
locked
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
The kernel source is in /usr/src/kernel. As discussed in class, you
should look in particular at files such as proto.h, proc.h, proc.c,
dmp.c, and keyboard.c.
You should re-read the material in the "monitor", "boot", and
"usage" man pages (particularly the "systems administration" section
of the latter); these are also available in the Minix section of the
course web page.
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
- Study the relevant kernel sources
- Modify selected code and headers in /usr/src/kernel
- "make" (in /usr/src/kernel, to rebuild the kernel)
- goto 1 if the compilation was unsuccessful
- "cd /usr/src/tools"
- "make fdboot" (to make a boot floppy)
- "shutdown" (to exit Minix)
- "exit" (to exit the boot monitor)
- The system reboots with the new kernel
- Test things carefully
- goto 1, as necessary
- Make a tar file "mods.tar" of the kernel files you've modified
- Write up your "README" file
- 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.
There are a number of shortcuts you can take in the above process;
see the man pages mentioned above, and read the makefiles, for more
information.