Re: [RFC][PATCH] inotify 0.10.0

[Ray Lee]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/