Re: fanotify - overall design before I start sending patches

[Eric Paris <eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

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...