Re: [GIT PULL] notification tree - try 37!

[Eric Paris]

On Tue, 2010-08-17 at 10:38 +0200, Andreas Gruenbacher wrote:
> On Tuesday 17 August 2010 05:39:47 Eric Paris wrote:
> > On Mon, 2010-08-16 at 22:32 +0200, Andreas Gruenbacher wrote:
> > > On Saturday 07 August 2010 21:15:14 Eric Paris wrote:
> > > > On Fri, 2010-08-06 at 20:06 -0400, Christoph Hellwig wrote:
> > > > > I'm also totally missing on any re-post of these patches or
> > > > > discussion of the changes during the last development window.
> > > > 
> > > > I just searched lkml an fsdevel where I usually send everything don't
> > > > see then.  I totally failed.
> > > 
> > > Oh yes.
> > > 
> > > This introduces two new syscalls which will be impossible to fix up after
> > > the fact, and those system calls are poorly documented: commits 2a3edf86
> > > and 52c923dd document the initial versions (in the commit message!), but
> > > subsequent commits then extend that interface.  The interface for
> > > replying to events is not documented at all beyond the example code [1].
> > >  There is no documentation in Documentation/filesystems/, either.
> > > 
> > > 	[1] http://people.redhat.com/~eparis/fanotify/
> 
> Oh ... this example doesn't actually build; both syscall prototypes are wrong.  
> What have you been testing this with?

I updated that code, I didn't realize just how out of date it got.

> > I'll work on documentation.  Although it should be pointed out that the
> > interface was sent to list many times with lots of discussion and
> > feedback.
> 
> One of the wonky remaining bits is the way how files are reopened with 
> dentry_open() with the f_flags passed to fanotify_init().  The open can fail, 
> in which case the user is left with an error condition but with no indication 
> as to which object the error happened for.  What the heck?

What else can be done?  When notification is based on an open fd and you
can't give them an open fd, there's nothing left....

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/