Message-Id: <1239151048.27468.25.camel@localhost.localdomain>
Date:	Tue, 07 Apr 2009 20:37:28 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
	hch@...radead.org, alan@...rguk.ukuu.org.uk, sfr@...b.auug.org.au,
	john@...nmccutchan.com, rlove@...ve.org
Subject: Re: [PATCH -V2 02/13] fsnotify: unified filesystem notification
 backend

On Tue, 2009-04-07 at 16:05 -0700, Andrew Morton wrote:
> On Fri, 27 Mar 2009 16:05:15 -0400
> Eric Paris <eparis@...hat.com> wrote:
> 
> > fsnotify paves the way for fanotify.
> 
> It'd kinda help if the changelog were to tell us what fanotify is.

In the next patch I'm sorta inclined to drop all reference to fanotify
since any hint of fanotify/TALPA/anti-malware puts a bad taste in
people's mouth.  This patch set is by itself an improvement.  It gives
us a wonderful plugin mechanism I can use to build fanotify (the
mechanism in fsnotify is based on the old fanotify code.  Using
foundation I do all fanotify implementation in less than 1100 lines) but
we aren't committing to anything.  These 13 patches (plus a couple more
for audit) should be taken on their own.  They stand alone as an
improvement.

But I'll explain fanotify right here.  fanotify is different for 2 main
reasons.  1) There isn't the huge race between the event and the
notification.  When an "event" is given to an fanotify listener it comes
with a magically opened file descriptor in the context of the listener.
With inotify I either have to keep the fd open for everything I'm
listening to or watch the parent directory and based on the name in the
inotify event try to open the file in question some time after the
original open.  By that time the file could have been moved, deleted, or
who knows what.

2) inotify and dnotify are both based on naming the couple of specific
files or directories you care about.  fanotify is about giving you every
single event on the system and letting you instead descript what you do
NOT care about.

I've got 3 users for fanotify.  The first user is the AV community.  The
ones who pushed hard enough that I'm writing all of this.  But we have 2
other users who are interested.

boot profiling: they currently get open/close/read/write type info by
hijacking audit.  fanotify fits perfectly.

the desktop search/filesystem indexer group has also expressed interest
http://lkml.org/lkml/2009/3/27/166 and it's simple to do what they want.

> I'm inclined to merge this patch series if only to get us an
> inotify/dnotify maintainer ;)

That's in here, and we actually have an inotify patch floating in the
ether I'm going to just stick into this series to see if anyone
notices....   :)

> General comment on the patches: complex.  I found them depressingly
> hard to understand (and hence review) - the lack of high-level
> commentary in the code is pretty severe.  There's a nice-looking design
> document there, but like everyone else, I didn't look at it much ;)
> It's not really a successful substitute for carefully-chosen comments
> at the appropriate codesites and data structures.

I'll make another pass based on your comments to the rest of the series
and try to throw more random comments even when you didn't ask.  I
realize I need to make it accessible to more than just Al.

-Eric

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

Powered by blists - more mailing lists