Messages in this thread | | | Subject | Re: [RFC][PATCH] inotify 0.10.0 | From | John McCutchan <> | Date | Tue, 28 Sep 2004 16:34:45 -0400 |
| |
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).
John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |