CS 3013 Operating Systems WPI,
A-Term 2008
Assigned: Tuesday, September 2, 2008 Due:
Monday, September 8, 2008 at 6:00 PM
This project is intended to introduce you to the process manipulation facilities in operating systems such as Linux, Unix, or Windows. You are to implement the programs described below so that they run on your virtual machine (i.e., that you created in Project 0).
Write a program in C called doit that takes another command as an argument, executes that command, and prints statistics about it. For instance, executing
% doit ls -l /usr/src
invokes the ls command to list the directory /usr/src. After execution of the specified command has completed, doit displays the following statistics about the system resources the command used:–
1. the elapsed “wall-clock” time for the command to execute in milliseconds,
2. the amount of CPU time used (both user and system time) in milliseconds,
3. the number of times the process was preempted involuntarily (e.g., time quantum expired, preemption by higher priority process, etc.),
4. the number of times the process gave up the CPU voluntarily (e.g., waiting for an I/O or resource),
5. the number of page faults, and
6. the number of page faults that could be satisfied from the kernel’s internal cache (i.e., reclaimed pages).
See below for how to get the information for these statistics.
You may not use the system call system() to execute the given command. Instead, you must extract the command from the input line, fork a new process, and cause that process to execute the command with its arguments using one of the variants of exec().
You may design doit for lines of input containing not more than 128 characters and not more than 32 distinct arguments. You should print an error if this condition is violated.
Satisfactory completion of this part is worth three of the ten points of the project.
You may actually do the work of this project on any suitable Linux system — for example, the CCC Linux environment (RedHat). However, it will be graded on the OpenSUSE 10.3 system of your virtual machine. Any differences in compilation or execution between the two environments are your responsibility, and the graders will not attempt to fix them or give allowances for errors arising from such differences.
One of the purposes of this assignment is for you to learn how to find information in the online documentation of Unix and Linux (called man pages) and, from that documentation, to learn how to invoke the various system facilities from your program.
For example, to learn about the fork() function, type
% man fork
to your favorite Unix or Linux shell. Manual pages are organized into sections. Section 1 is for commands to the shell, section 2 is for system calls, and section 3 is for library routines, etc. Some entries are contained in more than one section. For example,
% man wait
will give you the manual page for the wait command typed to a shell, while
% man 2 wait
will give you the manual page for the wait() system call.
% man man
tells you how to use the man command to view and/or print manual pages.
For this part of the assignment, the following systems calls are needed:–
· fork() — create a new process by cloning an existing one
· execvp() or one of its variants – execute a file. This is a front-end for the system call execve(), which replaces the current process with a new program to execute.
· wait() – wait for a process to terminate.
· getrusage() – get information about resource utilization.
· gettimeofday() – get current time for calculation of wall-clock time.
· strtok() – assistance in parsing strings.
Note: The getrusage() function returns a data structure with a lot of fields in it. However, the Linux man pages say that only some of these fields are actually populated by the Linux kernel. Students of a previous class determined that the information returned for a child of a process includes the cumulative sum for all children of that process that have ever terminated and been waited for.
Write a program in C similar to doit and call it shell to behave like a simple command shell. Your shell should continually prompt for commands, which may have multiple arguments separated by white space, and then it should execute each command the same way doit did and print the statistics as above.
Your shell should recognize and handle two “built-in” shell commands:–
· exit — causes your shell to terminate.
· cd dir — causes your shell to change the working directory to dir.
Your shell should also exit if an end-of-file is detected on input, and it should complain if an illegal command is typed.
Like doit, you may design your shell for lines of input containing not more than 128 characters and not more than 32 distinct arguments. You should print an error if this condition is violated.
A sample session of your shell is given below, with comments in /*…*/. The prompt of this example is ==>, but you may use a different prompt.
% shell
==>cat /etc/motd
/* print the text
of motd – i.e., the current message of the day */
/* print statistics
about the cat command */
==>cd dir
/* current
directory is changed to dir */
==>ls
/* listing of files
in the current directory */
/* statistics about
this ls command */
==>exit
% /* back to the prompt of your Linux shell
*/
A helpful function for this part of the project is
· chdir() – change working directory.
Satisfactory completion of this part of the project is worth three of the ten points.
Hint: Students in previous terms often rewrote doit to become shell. An alternative would be to make shell a wrapper around doit, so that doit gets the statistics of the specific command being executed. This way, the statistics are reported for each command, not the cumulative total of all commands invoked by shell.
Make a copy the shell program of part 2, and call this copy shell2. Design shell2 to handle background tasks, as indicated by putting an ampersand (‘&’) character at the end of an input line. When a task is run in background, shell2 should not wait for the task to complete, but instead it should immediately prompt the user for another command. Note that any output from the background command will be directed to the terminal display and will intermingle with the output from your shell and from other commands.
With background tasks, you will need to modify your use of the wait() system call so that (a) it returns if no process has terminated, and (b) you check the process id when it does return something. The returned process id might correspond to a background task rather than the currently invoked foreground task. In this case, your shell should print out the process id of the completed background task along with the command name. You also need to add the following additional built-in command to your shell:
· jobs – lists all background tasks currently active
A sample session with background tasks is given below.
% shell2
==*/numbercrunch &
[1] 12345 /* indicate
background task #1 and process id */
==*/jobs
[1] 12345 numbercrunch
/* print process id
and command name for tasks */
==*/ls
/* listing of files
in the current directory */
/* statistics about
this ls command */
==*/cat /etc/motd
[1] 12345 Completed .
/* indicate background command */
/* statistics about
background command */
/* print the
current message of the day */
/* statistics about
this cat command */
==*/exit
% /* back to Unix prompt */
If the user tries to exit shell2 before all background tasks have completed, then shell2 should refuse the exit, print a message, and wait() for those tasks to be completed.
As part of the write-up describing your program, you should observe how this mini-shell works in comparison to a regular Linux shell. Does it have all of the same features? What limitations does it have? Also, you must explain how your keep track of outstanding processes in shell2.
Satisfactory completion of this part of the project is worth three of the ten points.
Submit your assignment for grading as directed in class. We will use the web-based Turnin tool developed by Professor Fisler’s group. This can be found at
http://web.cs.wpi.edu/~kfisler/turnin.html
For purposes of Turnin, this assignment is Project 1. Your submission should include
1. All of the files containing the code for all parts of the assignment.
2. One file called Makefile that can be used by the make command for building the three executable programs. It should support the “make clean” command, “make all” and make each of the three programs individually.
3. The test files or input that you use to convince yourself (and others) that your programs actually work.
4. Output from your tests.
5. A write-up explaining your project and anything that you feel the instructor should know when grading the project. In particular, explain how you tested you programs. Write-ups in MS Word or PDF format are strongly preferred.
Do not put
separate parts of the assignment into separate folders or specify separate Makefiles
for them. Do not zip everything
together into a zip file. Be sure to put
your name at the top of every file you submit!
Each part of this assignment will be graded separately. Points will be assigned to each part as follows:–
· One point for compiling the program of that part with no warnings.
· One point for correctly executing the grader’s test cases.
· One point for submitting your own test case(s) that comprehensively test your program
In addition, one point will be awarded for a satisfactory write-up explaining your submission.
If your Makefile does not generate a working program for a part of this assignment, that part will not be graded and no credit will be awarded for it.
This is an individual project, not a team project. However, you may discuss the project with each other and work out one or more joint solutions. After you have worked out a joint solution, code up the project in your own style and write up the explanation in your own words.
Direct copying of each other or of solutions by others is a violation of the WPI Academic Honesty Policy.
Be sure to test your project on a virtual machine of this course, so that you are confident that it compiles correctly without warnings. Students who are teammates on a virtual machine should test their projects individually on that virtual machine.