From: Robert Love <rml@novell.com>
To: Steve French <smfrench@austin.rr.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
linux-kernel@vger.kernel.org
Subject: Re: which ioctls matter across filesystems
Date: Fri, 29 Apr 2005 16:50:35 -0400 [thread overview]
Message-ID: <1114807835.6682.156.camel@betsy> (raw)
In-Reply-To: <42729D51.5050203@austin.rr.com>
On Fri, 2005-04-29 at 15:47 -0500, Steve French wrote:
> I am not sure - but it is obviously required that inotify can pass over
> CIFS (and probably NFS) since change notification is hardest for the
> user to figure out when they are on a network. I am not sure how the
> filesystem can detect that a new watch is added to one of its inodes -
> it looks like you added an ioctl to a device but I am still reading
> through your latest patch. I was looking for something like an inode
> operation that cifs could hook so the fs could be told when a new watch
> was added or one was changed. In any case I need to construct
> functions somewhat similar to what is in fs/cifs/fcntl.c and need to
> finish/modify CIFSSMBNotify in fs/cifs/cifssmb.c to map the inotify
> flags to the flags available in the CIFS network protocol specifications.
> The existing network protocol support for ChangeNotify is more
> straightforward than you might think and the filter flags & actions that
> I have at my disposal for implementing notify across the network are in
> fs/cifs/cifspdu.h already (search for FILE_ACTION_ and FILE_NOTIFY_ if
> you are curious) but obviously they are similar to what the other Samba
> team guys have already told you.
So a client adds a watch and the server needs to then physically add the
inotify watch?
If you have a user-space, user-space could just add an inotify watch.
But I guess you live entirely in kernel-space? Couldn't we just export
our "add watch" interface to you?
Robert Love
next prev parent reply other threads:[~2005-04-29 20:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-29 19:22 which ioctls matter across filesystems Steve French
2005-04-29 19:53 ` Trond Myklebust
2005-04-29 20:03 ` Robert Love
2005-04-29 20:42 ` Trond Myklebust
2005-04-29 20:47 ` Robert Love
2005-04-29 21:13 ` Trond Myklebust
2005-04-29 21:22 ` Steve French
2005-04-29 21:38 ` Trond Myklebust
2005-04-29 20:55 ` Steve French
2005-04-29 20:57 ` Robert Love
2005-04-29 21:05 ` Steve French
2005-04-29 20:47 ` Steve French
2005-04-29 20:50 ` Robert Love [this message]
2005-04-29 21:00 ` Steve French
2005-04-29 20:32 ` Steve French
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=1114807835.6682.156.camel@betsy \
--to=rml@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=smfrench@austin.rr.com \
--cc=trond.myklebust@fys.uio.no \
/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.