From: Andrew Morton <akpm@osdl.org>
To: Robert Love <rml@novell.com>
Cc: ttb@tentacle.dhs.org, linux-kernel@vger.kernel.org,
gamin-list@gnome.org, viro@parcelfarce.linux.theplanet.co.uk,
iggy@gentoo.org
Subject: Re: [RFC][PATCH] inotify 0.10.0
Date: Mon, 27 Sep 2004 21:41:41 -0700 [thread overview]
Message-ID: <20040927214141.688b2b2c.akpm@osdl.org> (raw)
In-Reply-To: <1096318369.30503.136.camel@betsy.boston.ximian.com>
Robert Love <rml@novell.com> wrote:
>
> > > + memset(dev->bitmask, 0,
> > > + sizeof(unsigned long) * MAX_INOTIFY_DEV_WATCHERS / BITS_PER_LONG);
> >
> > What purpose does this bitmask serve, anyway??
>
> Bitmask of allocated/unallocated watcher descriptors.
Can you expand on that? Why do we need such a bitmap?
Would an idr tree be more appropriate?
> We _could_ take a fixed minor...
>
> > > +struct inotify_event {
> > > + int wd;
> > > + int mask;
> > > + int cookie;
> > > + char filename[INOTIFY_FILENAME_MAX];
> > > +};
> >
> > yeah, that's not very nice. Better to kmalloc the pathname.
>
> That is the structure that we communicate with to user-space.
In that case it looks rather 64-bit-unfriendly. A 32-bit compiler will lay
that structure out differently from a 64-bit compiler. Or not. Hard to
say. Perhaps something more defensive is needed here.
One other thing: the patch adds 16 bytes to struct inode, for a feature
which many users and most inodes will not use. Unfortunate.
Is it possible to redesign things so that those four new fields are in a
standalone struct which points at the managed inode? Joined at the hip
like journal_head and buffer_head?
Bonus marks for not having a backpointer from the inode to the new struct ;)
(Still wondering what those timers are doing in there, btw)
next prev parent reply other threads:[~2004-09-28 1:51 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-27 2:02 [RFC][PATCH] inotify 0.10.0 John McCutchan
2004-09-27 4:17 ` Andrew Morton
2004-09-27 20:52 ` Robert Love
2004-09-28 4:41 ` Andrew Morton [this message]
2004-09-28 2:14 ` Robert Love
2004-09-28 3:44 ` John McCutchan
2004-09-28 17:31 ` Robert Love
2004-09-28 5:45 ` Ray Lee
2004-09-28 19:08 ` Andrew Morton
2004-09-28 16:41 ` Chris Friesen
2004-09-28 16:53 ` Robert Love
2004-09-28 17:32 ` Ray Lee
2004-09-28 20:34 ` John McCutchan
2004-09-28 21:20 ` Ray Lee
2004-09-30 4:15 ` Andrew Morton
2004-09-30 1:32 ` John McCutchan
2004-09-30 1:34 ` Robert Love
2004-09-30 3:05 ` Paul Jackson
2004-09-30 5:37 ` Chris Friesen
2004-09-30 12:43 ` Paul Jackson
2004-09-30 15:29 ` Ray Lee
2004-09-30 16:27 ` Paul Jackson
2004-09-30 16:53 ` Ray Lee
2004-09-30 17:48 ` Paul Jackson
2004-10-01 1:22 ` Ray Lee
2004-10-01 4:09 ` Paul Jackson
2004-10-04 20:58 ` Ray Lee
2004-09-28 20:40 ` John McCutchan
2004-09-28 20:47 ` Robert Love
2004-09-28 21:39 ` Ray Lee
2004-09-28 22:10 ` Robert Love
2004-09-28 21:32 ` Ray Lee
2004-09-30 4:31 ` Andrew Morton
2004-09-28 20:26 ` John McCutchan
2004-09-28 21:10 ` Ray Lee
2004-09-28 21:20 ` Robert Love
2004-09-28 21:21 ` John McCutchan
2004-09-28 21:35 ` Robert Love
2004-09-28 21:50 ` Ray Lee
2004-09-28 22:03 ` Robert Love
2004-09-27 16:21 ` [gamin] [RFC][PATCH] inotify 0.10.0 [u] Martin Schlemmer [c]
2004-09-27 16:24 ` Robert Love
2004-09-27 16:30 ` Martin Schlemmer [c]
2004-09-27 16:35 ` Robert Love
2004-09-27 17:10 ` Martin Schlemmer [c]
2004-09-27 16:25 ` Martin Schlemmer [c]
2004-09-27 17:12 ` [RFC][PATCH] inotify 0.10.0 Robert Love
2004-09-27 19:48 ` Paul Jackson
2004-09-27 20:22 ` patch] inotify: use bitmap.h functions Robert Love
2004-09-27 20:38 ` Paul Jackson
2004-09-27 19:51 ` [patch] inotify: make it configurable Robert Love
2004-09-27 19:53 ` [patch] inotify: doh Robert Love
2004-09-27 20:06 ` [RFC][PATCH] inotify 0.10.0 Robert Love
2004-09-27 20:39 ` [patch] inotify: don't check private_data Robert Love
2004-09-28 1:05 ` [patch] inotify: silly fix Robert Love
2004-09-28 17:38 ` [RFC][PATCH] inotify 0.10.0 Mike Waychison
2004-09-28 20:35 ` John McCutchan
2004-09-28 17:48 ` [patch] inotify: remove timer Robert Love
2004-09-28 21:46 ` [patch] inotify: use the idr layer Robert Love
2004-09-28 21:58 ` John McCutchan
2004-09-28 22:08 ` Robert Love
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040927214141.688b2b2c.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=gamin-list@gnome.org \
--cc=iggy@gentoo.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@novell.com \
--cc=ttb@tentacle.dhs.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.