You are asked to extend Meng Ding's PTrace-based code to support the equivalent functionality of Scruf-Trace, as per Cam's M.Sc. thesis work. Your main deliverables are code and an executable, called ptrigger, that executes the trigger scripts (which you provide) in the current working directory (CWD), as per the rules of VFS Trigger Scripts. Your assignment should work on the Linux-based workstations in CSC 219.
|
When using fork() (and related functions) for the first time, it is easy have bugs that leave processes on the system, even when you logout of the workstation. It is your responsibility to clean up (i.e., kill) extraneous processes from your workstation before you logout. Learn how to use the ps and kill (and related) commands. |
|
Although many details about this assignment are given in this description, there are many other design decisions that are left for you to make. In those cases, you should make reasonable design decisions (e.g., that do not contradict what we have said and do not significantly change the purpose of the assignment), document them in your source code, and discuss them in your report. Of course, you may ask questions about this assignment (for example, in the newsgroup) and we may choose to provide more information or provide some clarification. However, the basic requirements of this assignment will not change. |
Your ptrigger should support trigger scripts as follows. If I type:
|
linux-prompt% ptrigger cat temp.file |
The ptrigger process should fork() a child cat process, use PTrace to catch the system calls issued by cat, and then invoke .on.open, .on.release (same as on.close), .on.read, .on.write, and .on.lseek trigger scripts, if they are present in the current working directory (CWD).
You should also provide trigger scripts that implement the equivalent of the Scruf-Trace functionality. For example, a timestamp and all calls and their parameters to the VFS file operations should be logged in a log file called ptrigger-trace.log. The format of the log file is a design decision on your part; you may choose to emulate Cam's log file format.
Of course, your ptrigger should work with arbitrary executables, in addition to cat.
At a minimum, your assignment should support the functionality of Scruf-Trace. However, you should also test your solution with other trigger scripts. For example, you could try to implement a simple form of Scruf-Trellis (for remote data access).
You can share (and borrow) trigger scripts with other students, as long as the program ptrigger is written by yourself.
You must write a Makefile for your program. You must use the gcc compiler. When someone types make, your Makefile must build ptrigger. When someone types make test, your Makefile must run a test to demonstrate the Scruf-Trace functionality. When someone types make clean, your Makefile must remove all executables (if any), all .o files (if any), all .a files (if any), and all core files (if any).
All of the following must be packaged into a tar file with the name submit.tar. Information about tar is available from the manual page (see man tar). For example, tar cvf submit.tar Makefile main.c my.h is an archetypal command; be very, very careful of the tar cvf submit.tar part. Before you submit, make sure your tar file works from within a fresh directory.
NOTE: Do not submit files or test data not described above. Only submit what is requested and what is required to compile your program Jan. 23/04 Comment about MEMWATCH files removed.
Also, make sure that your program does not produce any debugging or extraneous output. Only the requested output should be generated.
Note: All files in your submission must contain the identification information labelled (1) to (7) in point 1 above (e.g., as a C or Makefile comment).
The assignment is worth 10% of your final mark in the course. This is an individual assignment. Do not work in groups.
The assignment itself will be marked as follows: 20% for your report (clarity, technical accuracy, completeness, thoroughness of the testing, etc.), 60% for the correctness of the program when we test it using CSC 219, using gcc, and 20% for the quality of the implementation (design, modularity, good software engineering, coding style, useful and appropriate comments, etc.).
Your source code, as submitted, must compile and run (using the submitted Makefile) on the CSC 219 workstations using gcc.
All that you have learned about good technical communication (e.g., for your report) will apply. All that you have learned about good programming style and comments in your code will apply. Having correct code is important, but good style, design, and documentation are also important. We cannot provide an exhaustive list of what we will look for, but an incomplete list includes: a comment for each source code file, a comment for each procedure/function, a comment for each significant (global or local) variable, good choice of names/identifiers, proper modularity (e.g., do NOT put all/most of the code in main()) etc.
You may also want to learn about the following Unix programs: ps, grep, kill
Further hints may be given later on in the newsgroup, if warranted. Be sure to read the newsgroup on a regular basis.
Cleaning up runaway processes is good etiquette when using a shared computer. For this course, it is a necessity. Make sure you know how to use the ps and kill commands.