All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ray Lee <ray-lk@madrabbit.org>
To: Robert Love <rml@novell.com>
Cc: Chris Friesen <cfriesen@nortelnetworks.com>,
	Andrew Morton <akpm@osdl.org>,
	ttb@tentacle.dhs.org, Linux Kernel <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: Tue, 28 Sep 2004 10:32:51 -0700	[thread overview]
Message-ID: <1096392771.26742.96.camel@orca.madrabbit.org> (raw)
In-Reply-To: <1096390398.4911.30.camel@betsy.boston.ximian.com>

On Tue, 2004-09-28 at 12:53 -0400, Robert Love wrote:
> On Tue, 2004-09-28 at 10:41 -0600, Chris Friesen wrote:
> > Andrew Morton wrote:
> > 
> > > Why don't you pass a file descriptor into the syscall instead of a pathname?
> > > You can then take a ref on the inode and userspace can close the file.
> > > That gets you permission checking for free.
> > 
> > For passing in the data, that would work.  Wouldn't you still need a name or 
> > path when getting data back though?
> 
> Does Andrew mean an fd on the thing being watched?
> 
> That is what we are trying to fix with dnotify: the open fd's are pin
> the device and prevent unmount, making notification on removable devices
> impossible.

That's why he said to close the fd right after the syscall. But yeah,
for a case of someone wanting to watch their 1700 directories underneath
~/, thems a lot of open calls.

> Such a 1:1 relationship also opens way too many fd's.

...I'm not sure I follow. If you're talking about the IN_CREATE and
IN_DELETE events available when watching a parent directory, then I
don't think anything would change. IOW, why not do an open(2) on the
directory in question, and pass that fd in?

Regardless, Andrew's point still stands. What do we want the permission
semantics to be? One would think that a normal user account should not
be able to watch the contents of some other user's 0600 directories, for
example. open(2) already does all the correct checks. We should inherit
that work if at all possible.

Another benefit of passing in an fd, by the way, would be to make it
easier to make a write(2) interface to inotify, and get rid of the ioctl
one.

 ~ ~

As Chris points out, we still need a way to pass the name or path back
to userspace when an event occurs, which is the interface I was harping
on a few messages back.

It seems we're trying to recreate a variant struct dirent for
communicating changes to userspace. Perhaps we can learn something from
already trodden ground? Just sayin'.

Ray


  reply	other threads:[~2004-09-28 17:34 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
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 [this message]
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=1096392771.26742.96.camel@orca.madrabbit.org \
    --to=ray-lk@madrabbit.org \
    --cc=akpm@osdl.org \
    --cc=cfriesen@nortelnetworks.com \
    --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.