[lkml]   [2004]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] inotify 0.10.0
On Tue, 2004-09-28 at 13:32, Ray Lee wrote:
> 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.

Yes we should, but I think the inotify interface would be cleaner if we
just factored out this permission code and called it from open() and
from the inotify code.

> 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.

I don't see how passing directories/files to inotify by fd not filename,
makes providing a write(2) interface to inotify any easier. To me they
are mutually exclusive. When you open up /dev/inotify, you get an fd,
you read events from it. We could provide write on that fd instead of
the ioctl() interface.

> ~ ~
> 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'.

Yes the current method of passing the name back to user space is
definitely sub par. But I don't think passing a full path to user space
is reasonable, as that would require walking the dirent tree for every
event. Really the best we can provide user space is the filename/dirname
(relative to the directory you are currently watching).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:06    [W:0.063 / U:2.504 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site