[lkml]   [2009]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: fanotify - overall design before I start sending patches
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

-- Jamie

 \ /
  Last update: 2009-07-25 01:49    [W:0.095 / U:2.480 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site