Hello,

I have made some changes the the inotify interface, and I hope this
makes Al Viro happier with the design.

Inotify no longer deals with inode numbers or device numbers. When you
want inotify to monitor a dir you pass a path in string form. Then
inotify opens up this file and does what it did before on the inode.

This avoids the problem with file systems not having stable inode
numbers, and not being able to lookup a file based on its inode number.

When you ask inotify to watch a path, you get back an integer,
representing a unique watcher in the kernel (wid). So when events happen
you get a WID followed by and event mask. And when you are done watching
a path, you just pass the wid to inotify.

I am sure there are still problems with the code. I have tried to fix up
locking issues but I am not very confident in my locking code. 

This hasn't dealt with hierarchy watching, and I don't plan on looking
in to this until this phase of the project is finished.

There are still two areas that I need help on, they involve VFS work. 
I have added a new entry to the inode structure, 'watcher_count'. This
is meant to be a passive usage count on the inode, so if watcher_count >
0 the inode should stay in the cache, but on unmount we kick the
watchers off. So the two changes I need to make to the VFS are this:

1) when watcher_count > 0 the inode is considered in use and stays in
the inode cache. I have modified prune_icache to do this, but I am not
sure if this the only place that needs modification.

2) On unmount, after we have assured that all the inodes in the cache
that come from a particular device have i_count == 0. We walk and kick
off (send an UNMOUNT event to inotify and have inotify stop watching the
inode) all watchers so that we get watcher_count == 0. Then the standard
unmount procedure takes place. I can't figure out how this logic would
fit in to unmount code, I have tried to trace the unmount system call,
but I haven't figured it out yet.

I have attached the new code. I await your comments.

John