Eric Paris wrote: > On Fri, 2009-07-24 at 23:48 +0100, Jamie Lokier wrote: > > Eric Paris wrote: > > > It is a new notification system that has a limited set of events (open, > > > close, read, write) in which notification not only comes with metadata > > > the describes what happened it also comes with an open file descriptor > > > to the object in question. fanotify will also allow the listener to > > > make access decisions on open and read events. This allows the > > > implementation of hierarchical storage management systems or an access > > > file scanning or integrity checking. > > > > My first thought was to wonder, why not make it the same set of events > > that inotify and dnotify provide? That is: open, close, read, write, > > create, delete, rename, attribute change? In other words, I don't see > > a good reason for it to be a subset of events. > > The two real reasons? > > 1) These were the only 4 my original use case cared about. > 2) These are the only 4 where the notification hook has enough > information to open a fd in the context of the listener. > > In the kernel most notification is done with either an inode or a dentry > as that is enough for inotify, dnotify, audit_watch and audit_tree. > Opening a file descriptor, and thus fanotify, requires a dentry and a > vfsmnt, which is much harder to come by in the kernel. > > Maybe as future work I'll try to convince Al to allow me to have that > information in more places, but for today, those 4 are the only ones I > can probably slip past him... For the other events, maybe there is no need for a file descriptor anyway. -- Jamie -- 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
