On Thu, 2012-08-16 at 17:54 +0400, Cyrill Gorcunov wrote:
> On Thu, Aug 16, 2012 at 02:50:19PM +0100, Al Viro wrote:
> > On Thu, Aug 16, 2012 at 05:47:06PM +0400, Pavel Emelyanov wrote:
> > > On 08/16/2012 05:43 PM, Al Viro wrote:
> > > > On Thu, Aug 16, 2012 at 04:38:14PM +0400, Cyrill Gorcunov wrote:
> > > >
> > > >> Hi Bruce, thinking a bit more I guess using general encode_fh is not that
> > > >> convenient since it operates with dentries while our fdinfo output deals
> > > >> with inodes. Thus I should either provide some new encode_fh variant
> > > >> which would deal with inodes directly without "parents". Which doesn't
> > > >> look for me anyhow better than the new export_encode_inode_fh helper.
> > > >
> > > > Huh? You do have dentries, for crying out loud...
> > >
> > > Sometimes we don't -- the inotify thing gets an inode only.
> > > Unlike other notifies that have dentries at hands...
> >
> > What's wrong with saying "we don't support idiotify"?
>
> Al, we need some way to restore inotifies after checkpoint.
> At the very early versions of these patches I simply added
> dentry to the inotify mark thus once inotify created we always
> have a dentry to refer on in encode_fh, but I'm not sure if
> this will be good design.
Actually, I was about to suggest this. This can be done internally
within fs/notify without actually modifying the syscall interface, can't
it, since they take a path which is used to obtain the inode? It looks
like the whole of the inotify interface could be internally recast to
use dentries instead of inodes. Unless I've missed something obvious?
James
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
