[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081125161435.f65d6f06.akpm@linux-foundation.org>
Date: Tue, 25 Nov 2008 16:14:35 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Eric Paris <eparis@...hat.com>
Cc: linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
viro@...iv.linux.org.uk, alan@...rguk.ukuu.org.uk,
arjan@...radead.org, hch@...radead.org, a.p.zijlstra@...llo.nl
Subject: Re: [PATCH -v3 0/8] file notification: fsnotify a unified file
notification backend
On Tue, 25 Nov 2008 12:20:51 -0500
Eric Paris <eparis@...hat.com> wrote:
> This series only reimplements dnotify using the new fsnotify backend. If
> accepted I will do the work to port inotify as well. Currently struct inode
> goes from:
>
> #ifdef CONFIG_DNOTIFY
> unsigned long i_dnotify_mask; /* Directory notify events */
> struct dnotify_struct *i_dnotify; /* for directory notifications */
> #endif
>
> to:
> #ifdef CONFIG_FSNOTIFY
> unsigned long i_fsnotify_mask; /* all events this inode cares about */
> struct list_head i_fsnotify_mark_entries; /* fsnotify mark entries */
> spinlock_t i_fsnotify_lock; /* protect the entries list */
> #endif
>
> so the inode still grows, but the inotify fields will be dropped as well
> resulting in a smaller struct inode. These are all the fields fanotify will
> want as well.
Did you consider using i_lock to protect that list? Its mandate is "an
innermost lock which protects fields within the inode".
> 29 files changed, 3100 insertions(+), 1977 deletions(-)
if (code > code_reviewers)
fix();
but how?
--
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