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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
