Re: [RFC][PATCH] inotify 0.10.0

[Paul Jackson]

Ray wrote:
> > So passing back an inode number doesn't come close to reintroducing
> > the forced tracking of all the interesting stat data of every file.
> 
> It certainly forces userspace to track all file names and inodes, at
> least. Userspace wishes to know about deletes and renames. Unless it
> caches everything, it won't know what was deleted, or what got renamed.

Aha ... you finally got through my thick skull.  Congratulations ;).

If file "foo" goes away, and if the kernel only reports that inode
314159 was unlinked from a given directory, unless some user code
previously remembered that inode 314159 was accessible from the
directory entry named "foo", you can't tell the user that "foo"
disappeared.

Do you have the same problem with directories, if some cookie, not the
full pathname, is passed back after an 'rmdir(2)' event?  Or is it just
that it's less onerous to track all the directories, because there's
fewer of them?


> You're saying pass the inode number, as it's smaller and makes for an
> easier and higher speed interface to get changes to userspace (if I
> understand you correctly).

That was the idea, yes.  Most of it anyway.  That and striving to keep
the API the kernel presents to the user minimal and orthogonal.


> I'm saying that if the kernel has the information already, and we're not
> passing it to userspace, and userspace *needs* that information, then
> all we've done is guarantee another long set of syscalls while it tries
> to pull the directory contents to match up item for item against its
> cache of previously known file states.

If there is a way, any way, for user code to get something from the
kernel, then I don't mind dragging my feet on providing other ways,
until I see a good reason.  It's always worth a bit of effort to keep
kernel API's minimal and orthogonal.

Your "delete and rename" point above seems now like a good reason.


> I've been avoiding saying this, as this really will be a bit more
> complex than even my suggestions, but perhaps everyone would be happier
> if we crammed all this through a netlink socket instead. Got me.

No comment ;).

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@xxxxxxx> 1.650.933.1373
-
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/