Monitoring FS changes

[Bakul Shah]

Why not do this (at least at first) in a user mode program?
Intercept FS system calls and write relevant info to a user
program's memory.  You still need to add a syscall to watch
files/dirs for various events and to validate requests. This
will allow you to experiment with various implementations
before commiting to a complicated new mechanism in the kernel.

Something like:
For the client:

	fd = new_watcher();
	watch(fd, path, flags); // can add multiple watches
	count = read(fd, buf, sizeof buf);

flag = 0 => remove watchpoint.
flag = recursive => watch everything underneath a tree (on the same fs)
other flag decide the events you want to watch.

read returns one or more events.

For the watcher:

	fd = register_watcher(buf, length);
	fd1 = get_watcher(fd, &path, &flag);

The watcher mmaps a bunch of space and the kernel uses it as a
circular buffer.  The watcher can create a map of inode-id to
subscribers: a list of <fds,events> or a ptr to a list. The
indirection should make recursion cheaper to handle: objects
will point to parent dir in a recursive watch. You'd still
need to spend something like 8 bytes per file or dir (on a 4GB
addr space system).

flag = 0 => unsubscribe fd from watching the path.
close the fd when the number of watches is 0.
On a client disappearing path is NULL.

On a watcher disappearing all clients get one final event.

Hard links are not a problem: such a file will just have N
items on its list, one per watched dir.

Multiple watchers, each handling a different set of clients,
should be possible with a little extra cost. Basically what
we are doing is outsourcing most of the actual work to the
watcher but the kernel still have to tell all the watchers
when something changes.

Very likely the same mechanism can be used to report process
deaths or dead network connections etc.

Undoubtedly I have missed a bunch of things here!