On Wed, 2005-07-13 at 15:21 -0500, Steve French wrote:
> I did not think that inotify_add_watch called dir_notify. I don't see a path
> in which
> calls to add a new inotify watch end up in a call to fcntl_dirnotify or
> file->dir_notify
> This is for the case in which an app only calls inotify ioctl - ie does not
> [also] do a call
> to dnotify.
No, you are right, they do not, right now.
Is dir_notify suitable for inotify and your uses? In the 10 months of
inotify development, I had hoped that a remote filesystem developer
would add support so we could test it. But there is no rush to get this
hook added, so its okay.
The problem with dir_notify is that the args parameter is dnotify flags.
Those don't map directly to inotify flags.
What I'd like is
(a) a patch adding the requisite inotify hook (really, 4 lines)
(b) a filesystem successfully using the hook
> Without such a call - an app that does your new ioctl to add a watch on a
> file or directory will
> not cause the network/cluster fs to turn on notification on the server since
> the watch
> will be not seen by the client filesystem.
It is a system call, now. ;-)
> OK - you exported a common underlying function
> inotify_inode_queue_event
> under the inline functions which the network/cluster fs would call to notify
> of remote changes.
> That makes sense. I had missed that.
Nod.
Robert Love
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
