On Tue, 2009-09-15 at 16:49 -0700, Linus Torvalds wrote:

And btw, I still want to know what's so wonderful about fanotify that we 
would actually want yet-another-filesystem-notification-interface. So I'm 
not sayying that I'll take a system call interface.

The real thing that fanotify provides is an open fd with the event
rather than some arbitrary 'watch descriptor' that userspace must
somehow magically map back to data on disk.  This means that it could be
used to provide subtree notification, which inotify is completely
incapable of doing.  And it can be used to provide system wide
notification.  We all know who wants that.

It provides an extensible data format which allows growth impossible in
inotify.  I don't know if anyone remember the inotify patches which
wanted to overload the inotify cookie field for some other information,
but inotify information extension is not reasonable or backwards
compatible.

fanotify also allows userspace to make access decisions and cache those
in the kernel.  Useful for integrity checkers (anti-malware people) and
for hierarchical storage management people.

I've got private commitments for two very large anti malware companies,
both of which unprotect and hack syscall tables in their customer's
kernels, that they would like to move to an fanotify interface.  Both
Red Hat and Suse have expressed interest in these patches and have
contributed to the patch set.

The patch set is actually rather small (entire set of about 20 patches
is 1800 lines) as it builds on the fsnotify work already in 2.6.31 to
reuse code from inotify rather than reimplement the same things over and
over (like we previously had with inotify and dnotify)

Don't know what else to say.....

-Eric