Due date: 2/2

Outline of the project objectives

• the Minix operating system that we will be using and studying in this course,
• the "Minix computer" is the Sheppard Lab that your team will be using on all projects,
• booting Minix on the different disk partitions of this machine,
• booting using the boot diskette (in emergency),
• using diskettes to hold and transfer programs and data,
• using a text editor in Minix,
• compiling and executing a C program in Minix,
• exploring some system commands,
• changing and rebuilding the Minix kernel, and
• recovering from a catastrophic rebuild of the kernel.

Submitting and grading

Details about the assignment

1. Each of you was given a Minix boot diskette for two possible purposes:
   
   
   • To help you get started installing Minix at home if you so desire.
   • To bring with you to Sheppard Lab (every time - please) in case the boot partition on the hard drive of the Minix computer should ever becomes corrupted. You will practice using this in a moment.
   
       The Minix computer has been set up with four copies of Minix in four different hard disk partitions. Most of the time, you will be booting and using the copy on the first partition, which is refered to as hd1. This is automatically booted when you turn on the computer, assuming that the floppy drive is empty. Try this. Notice that you are prompted to press the "=" key along the way. When the login prompt appears, enter your team's account name. When prompted for a password, enter the password you were given in class. After logging in, immediately run passwd to change your team's password to something mutually agreed upon, and please keep this private. Then log out by give the command exit. Log in again to test the new password.
   
       Then issue the command halt to shutdown ("unboot") Minix. (If I ever forget to activate this command for you, you can use the CTRL-ALT-DEL key combination instead after logging out.) Wait until you see the prompt hd1a> appear. This prompt is not the Minix command prompt. Rather it is a boot monitor prompt. From here you can reboot any of the four copies of Minix on the four different disk partitions. Why so many copies of Minix? The copy on hd1 is set up so that you will log in using your team's account name, and you here have only limited powers. You will not be making changes to this copy of the system.
   
       The other three copies of Minix (on hd2, hd3, hd4) have only a single account set up, which we will share, namely the root account. When you log into root (no password required) at one of these three copies of Minix, you will be a superuser, and so will have unrestricted powers. Consequently, you will easily be able to corrupt the OS here. There are three such copies of Minix though, so unless all three become corrupted, it will be possible for you to continue working, provided you've backed up your source code.
   
   Please let me know whenever a copy of Minix gets clobbered.
       There will be many times, such as in the last exercise in this lab assignment, when you will be asked to work in this unrestricted environment. On such occasions, please be cautious and conscientious. Out of consideration for others, please remember to always leave hd2, hd3, hd4 EXACTLY as you find them.
   
   Undo any changes made to the system, and do not leave any of your files on hd2, hd3 or hd4.
   I am prepared to reinstall copies of Minix as necessary, but I am hoping to keep such reinstallations to a minimum. OK, that said, you are ready to boot Minix on the second partition by giving the boot command boot hd2. Log it as root. After logging in, use the command halt to drop the system. Then, at the boot monitor prompt, use boot hd1 to return to the restricted copy of Minix.
   
       It is now time to test the boot diskette I gave you. Get to the boot prompt. Power off the computer. Then boot the computer with the diskette in the drive. When prompted to finish the name of the device to mount as /usr, type fd0c and hit return. Do not log in at the login prompt. Instead, use CTRL-ALT-DEL to get a boot monitor prompt. Then boot one of the four copies of Minix on the computer's hard drive. You are being taught this in case hd1 fails to boot automatically due to corruption, so that you will at least be able to boot one of the other copies of Minix. Please remember to bring your boot diskette with you to the Sheppard Lab each time, just in case. This is your responsibility.
   
   
   
2. The next step in our initiation into Minix is to discover how to transfer files to and from diskettes. We will consider doing this for DOS-structured diskettes as well as Minix-structured diskettes. You will need two diskettes, at least one of which is DOS-formatted, perhaps the diskettes you were given in class, apart from the Minix boot diskette. Let's first deal with files on DOS-structured diskettes.
   
       While you're at it, you'll compile and run a fun little C program I found on the internet. These labs will involve some C programming, recognizing that some students are confortable with Java, but not C. You will be introduced to the needed C constructs as we go along. The program I want you to download can be found here. (Last time I taught this course I used somebody else's Life program, but it's now gone.) You should save this in a text file named "life", on a diskette. You need to edit this file in order to remove the stuff at the top that is not part of the program. Do this at home before you come to the lab. Transfer this diskette to the Minix computer in the lab. Log into your account on hd1. Then type

   dosdir /dev/fd0

   to see what's on the diskette. After this, type

   dosread -a /dev/fd0 life.txt > life.c 

   Type ls to check that you got the file. Then type yap life.c to view the contents of the file. Use the arrow keys, enter key and space bar to move through the text. Use the q key to quit. (yap works like less, which you're perhaps familiar with in Linux.) Then compile it using

   cc life.c -lcurses -o life

   Then give the command life to execute it. Use CTRL-ALT-DEL to kill the program, and also exit Minix. Then reboot using boot hd1 and log in again.
   
       You will also get some exposure to at least one of the three available text editors on the Minix computer. There are three text editors available to you: an emacs-like editor called elle, a vi-like editor called elvis, and a friendly editor called mined. You can play with these. You can read the man page for each. For example, type man mined to learn about the mined text editor. You can also find more info on these at sites linked to the bottom of our course page. Figure out what you like and use it. Experiment with the life.c file. Try altering it a bit to get the hang of the text editor you opted to use. You don't need to submit anything concerning this.
   
   
3. Minix has its own file system structure. It is possible to structure the files on a diskette using this system, and to mount (attach) this to Minix's overall file system. (Many of you have no doubt had experience with a similar situation in Linux.) To get exposure to doing this in Minix, do the following:
   
   
   • format a diskette using     format /dev/fd0 1440
   • add a Minix file system to it using     mkfs /dev/fd0
   • mount this to the overall file system using     mount /dev/fd0 /fd0
   • copy a file to the diskette using     cp life.c /fd0
   • view this using     yap /fd0/life.c
   • unmount the diskette using     umount /dev/fd0
   
   Note: You are responsible for backing up all your own files, after each session, onto diskettes to protect these files from harm. Also you should not leave any of your files on hd2, hd3 or hd4. It is OK to leave some small files on hd1, but be reasonable about this, and don't expect these files to be there when you come back.
   
   
   
4. The next exercise is to examine some of the system commands available to you in Minix. Change directory using cd /usr/bin and then view the (executable) files there using ls | yap . Some of these should look familiar to you from Linux. Spend a little time exploring the manual pages for some of the commands that look alien to you. Explain carefully what each of the following commands does:
   
   
   • man man
   • whatis whatis
   • whereis whereis
   • which which
   • yap yap
   • size size
   • du du
   • du
   • ls -ls ls
   • ls -alsFR
   • grep grep *
   • pwd
   
   Your answers to these questions should be submitted and can be handwritten.
   
   
   
5. The final exercise involves making small changes to the Minix kernel, rebuilding it, and rebooting Minix to see the effect. You will also learn how to recover from any catastophic changes made to the kernel. Proceed as follows:
   
   
   • Boot up Minix on hd2 (or hd3 or hd4), and log in.
   • Move into the directory /usr/src/kernel.
   • Copy the file proc.c to proc.c.old.
   • Edit proc.c, add the statement printf("."); to the top of the function interrupt() (page 604 of your textbook), but add it after any parameter and local variable declarations (old-fashion C programming necessity: executable statements come after variable declarations).
   • Save the change and exit the text editor.
   • Move into the directory /usr/src/tools.
   • Give the command make clean, followed by the command make hdboot, and wait for the completion of the rebuild.
   • Give the command reboot to reboot the Minix OS, and log in.
   • Notice the effect your change to proc.c had on the system behavior.
   • Give the halt command, and then, at the boot prompt, boot Minix on hd1 and log in.
   • Issue the command fix_kernel 2 to restore the original kernel on hd2. (fix_kernel is a script I wrote, found in /usr/bin.)
   • Now halt and reboot hd2 again, and log in.
   • Restore the source file proc.c to its original form, either by hand or by copying proc.c.old.
   
       Rebuilding the kernel like this is dangerous, and can often be disasterous, and result in a situation where Minix won't reboot. However, as you observed, you can restore the kernel in hd2, hd3 or hd4 from within hd1. Also, if hd1 should somehow become corrupted (it shouldn't if you are reasonably careful), you can always boot one of the other partitions by means of the boot diskette I gave you. However, in this case, if you then need to copy the kernel from say hd3 to hd4 (due to a corrupt kernel on hd4) you'll need to mount /dev/hd4a (not hd4) to some empty directory in the file system on hd3, and copy the kernel from hd3 to hd4. This will probably never be necessary, but you should observe how fix_kernel does the job, one command at a time, just in case.
   
       Now, repeat all of the above bullets except instead of changing the function interrupt() in proc.c, change the function sys_call() (page 605 of your textbook) in the following way, by adding some code just before the statement rp = proc_ptr;. First note that this function assists in passing messages between processes. Its first parameter, called function, takes on one of three values: SEND, RECEIVE, BOTH (constants defined elsewhere). This parameter determines whether the currently executing process needs to send or receive a message to/from another process, or both. The next parameter indicates the identity of this other process, by means of an integer identifier. The last parameter points to the message.
   
       Also note that the global variable proc_ptr is a pointer that points to a structure (complex data similar to an object in Java) associated with the current process. This structure is called proc and is defined in proc.h (page 581 in your textbook). Notice that one of the fields in this structure is an integer identifier for the process, called p_nr. In order to refer to the p_nr field of the structure pointed to by proc_ptr you would say proc_ptr->p_nr. This would be the integer identifier for the current process.
   
       Here is what I want your code to cause to be displayed between angle brackets: If sys_call is being used to send a message, display the letter "s". If it is suppose to receive a message, display the letter "r". After following this by a space, display the ID of the current process, followed by a space, followed by the ID of the other process. Do not print any carriage returns. After you've got this working, transfer your source code (altered proc.c) to a DOS diskette, print this file, and submit the printout along with your other submitted work.
   
   
   Please turn off the computer and video monitor after logging out. Please remember to do likewise in the future.