One type of systems application is a scheduler that sends reminders or executes tasks at a particular time. In Unix, such applications include cron, which is a daemon (server) program that runs commands at specified dates and times scheduled with the commands crontab or at. These applications use the system clock and system calls such as sleep() and select() to wake up at appropriate times and perform an action.
It might also be advantageous to take an action when other system events occur. One such an event could be when a file is modified. The modification of a source file could trigger a command to recompile it, the modification of a mail spool file could trigger a ``Mail is here'' window popping up on the screen (assuming other mechanisms were not available).
In this project and the next you will be implementing different approaches in the Linux kernel to detect when files are modified and for a user-level process to be notified. In this project you will be implementing two less efficient solutions to solving the problem. In the next project you will be implementing a better solution.
The first part of the project involves no kernel hacking. You need to
create a user-level application called filewatch, which takes the
name of a file on the command line as input and prints out a message each
time the file is modified (by some other process, such as with touch command). The program should run forever, until terminated by a
^C (SIGINT software interrupt). When the interrupt is received, it
should print the total time it has been executing, the number of file
modifications it detected and the total ``miss time'' (difference between when
a file modification occurred and when it was detected). Here is a sample
execution:
% filewatch testfile
testfile modified at Thu Mar 15 11:42:49 EST 2001
detected at Thu Mar 15 11:43:00 EST 2001
Miss time = 11 seconds
testfile modified at Thu Mar 15 11:44:01 EST 2001
detected at Thu Mar 15 11:45:00 EST 2001
Miss time = 59 seconds
^C
Total execution time: 257 seconds, 2 modifications detected,
total miss time = 70 seconds.
You should implement your program using the stat() system call to obtain the file modification time and use the sleep() or select() system calls to check this value every minute. You will also need to create an interrupt handler to handle a SIGINT software interrupt. You can use the ctime() function to print the time as text.
The next part of the project is to replace the use of the stat() system call in your application with the GetFileModTime() system call. This is a new system call that you will need to create. Its definition is
int GetFileModTime(char *file_name, time_t *mtime)
where it takes a file name and returns the current modification time. Just like stat(), it should return zero on success and -1 if an error occurs.
This system call provides information already available using stat(), but its creation is intended to give you experience in implementing a straightforward system call within the Linux Virtual File System. You should pay careful attention to the Fossil Lab Web page on ``Adding a System Call'' to Linux and at how the existing stat() system call is implemented.
Your filewatch application should perform exactly the same after replacing stat() with GetFileModTime().
Note: When writing kernel code, you will want to print messages to stdout, as you do in printf(). Since many parts of the kernel may not have access to the stdio library, kernel developers wrote their own version of printf() called printk(). printk() basically behaves the same as printf(), in terms of formatting. Furthermore, printk() also writes messages to the log file /var/log/messages, so you can view output there in case your modified OS crashes. You might add prefixes to your printk() messages, such as "CEW: " or "Fossil: " so you can more easily pick out your messages from the log file. Be careful! If you have printk() messages in a part of the kernel that is accessed frequently it can fill up your log file quickly. When this happens, your system can become unstable. Check the size of your log file (using ls -l) and the disk space that is free (using du) frequently.
You are advised to take a conservative, incremental strategy for developing this system call (and any kernel work). First focus on putting printk() statements into some of the key parts of the Linux virtual file system to build up confidence as to where to add your modifications.
The last part of this project involves changing the wpi file system (not the ext2 file system) so that whenever an existing file is modified (not when a new file is created), you should use the printk() call to add a message to the system log file. The message should look like the following:
FILEMOD inode# systime
where FILEMOD is for easy identification in the log. The remainder
of the line is the numeric inode of the modified file (st_ino
field of the stat structure) and the system time in seconds.
You will write a second user-level application, filewatch2, which will use the system log file to watch for file changes in the wpi file system. This application should open the system log file for reading and block until new lines are appended to the log. It should not process existing lines in the log. When your application reads a new line, it should see if it matches the watched file and if so then print output as done for the filewatch application. Note that your application will need to obtain the inode number for the watched file to match it with a logged entry. If a new log entry does not match a file modification for the watched file then ignore it.
As part of your project, you need to compare the results of your two applications in terms of the total miss time and the total number of modifications detected. What are inefficiencies in each approach?
The basic objective of the project is to complete the user-level and kernel-level work needed to implement the two filewatch applications. Successful completion of the filewatch application without kernel modifications is worth 10 points. Completion of this application using the GetFileModTime() system call is worth 20 points. Additional completion of the second application is worth 28 points.
To receive full credit for the project you need to extend the implementation of each application to handle an arbitrary number of files on the command line. Your program should report the same output as previously shown if any one of the files is modified.
Details on submission of the project will be provided near the project completion date.