From: Robert Love <rml@novell.com>
To: Ray Lee <ray-lk@madrabbit.org>
Cc: John McCutchan <ttb@tentacle.dhs.org>,
Chris Friesen <cfriesen@nortelnetworks.com>,
Edgar Toernig <froese@gmx.de>,
Linux Kernel <linux-kernel@vger.kernel.org>,
viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: [RFC][PATCH] inotify 0.9.2
Date: Thu, 23 Sep 2004 01:10:47 -0400 [thread overview]
Message-ID: <1095916247.2454.188.camel@localhost> (raw)
In-Reply-To: <1095915177.4101.63.camel@orca.madrabbit.org>
On Wed, 2004-09-22 at 21:52 -0700, Ray Lee wrote:
> [*] Here's one of those things that makes me think that I'm
> talking out my tush. The comments claim that only the filename
> will be returned to userspace, but later on another comment says
> that the size might technically fly up to PATH_MAX. Wassup?
Technically speaking, a single filename can be as large as PATH_MAX-1.
The comment is just a warning, though, to explain the dreary theoretical
side of the world. Pragmatism demands that we just use
INOTIFY_FILENAME_MAX, which is a more reasonable 256.
> BTW:
> <pedantic>
> + unsigned long bitmask[MAX_INOTIFY_DEV_WATCHERS/BITS_PER_LONG];
>
> would be more correct if written
>
> unsigned long bitmask[(MAX_INOTIFY_DEV_WATCHERS + BITS_PER_LONG - 1) / BITS_PER_LONG];
>
> </pedantic>
Indeed! Although we define MAX_INOTIFY_DEV_WATCHERS right above and it
is a power of two.
> BTW #2: 'mask' is variously declared as an unsigned long and other times
> as an int. Granted, the two base declarations seem to live in different
> structs, but I can't figure out when a mask-like thing would want to be
> signed. Please consider either changing the name or, more likely,
> changing all usages to unsigned. My single linear reading through the
> patch hasn't quite clarified the usage to me.
Probably should just be an 'unsigned int' everywhere.
But there are a few variables that have the same name in various
structures. That confuses me to no end, but I am jumpy like that.
> P.s. Have I mentioned that I like the inotify idea a heck of a lot
> better than dnotify? Ghu save us from people who think signals are a
> wonderful way to communicate complex information.
Oh, dude, inotify is a godsend.
Robert Love
next prev parent reply other threads:[~2004-09-23 5:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-20 3:56 [RFC][PATCH] inotify 0.9.2 John McCutchan
2004-09-20 21:52 ` Robert Love
2004-09-21 5:21 ` Robert Love
2004-09-21 15:34 ` Edgar Toernig
2004-09-21 15:43 ` Chris Friesen
2004-09-22 2:27 ` John McCutchan
2004-09-23 1:46 ` Ray Lee
2004-09-23 3:42 ` John McCutchan
2004-09-23 4:52 ` Ray Lee
2004-09-23 5:10 ` Robert Love [this message]
2004-09-23 5:29 ` Ray Lee
2004-09-21 15:46 ` Robert Love
2004-09-21 5:26 ` Robert Love
2004-09-21 5:44 ` Robert Love
2004-09-21 16:04 ` Robert Love
2004-09-21 18:56 ` Robert Love
2004-09-21 20:55 ` Robert Love
2004-09-22 2:32 ` John McCutchan
2004-09-22 3:49 ` 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=1095916247.2454.188.camel@localhost \
--to=rml@novell.com \
--cc=cfriesen@nortelnetworks.com \
--cc=froese@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ray-lk@madrabbit.org \
--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.