On Sat, May 20, 2000 at 03:31:29PM -0400, Erez Zadok wrote:
> I looked briefly at the patch, and I'm afraid I don't understand some basic
> things. Perhaps you can let us (-fsdevel) all know the following (which you
> should probably put in a README on your Web page along w/ the patches):
> - what is directory notification
> - what is it good for
Directory notification is a mechanism for informing interested tasks
when the contents of a directory change. This has immediate applications
for file managers and ps. Samba benefits from this, and there are some
non-obvious applications such as a persistent make which perpetually
keeps a tree up-to-date by noticing modifications to files.
> - (is it related at all to notify_change or the old check_media_change?)
> - why it cannot be done using other mechanisms
notify_change() is not called in all the situations where we need to be
notified.
> - an overview of how it can be used (I couldn't understand it from your test
> program)
It delivers a realtime signal to tasks which have requested it. The task
can then call fstat to find out what changed.
> - an overview of what your patch does. (Your patch seems rather long. You
> should explain on this list why it is that long, what it does, etc.)
There are really 4 conflated patches here:
* A rewrite of the fs/locks.c code.
* Making kill_fasync() SMP-safe.
* Directory notification.
* Addition of file leases.
I should split them up.
> - what impact, if any, does your patch have on the rest of the kernel and
> other file systems.
It delivers a lot more signals when someone's using the feature.
The impact on other filesystems was what I want to ask you about.
I'm currently doing the notify from within the vfs_* functions which
seem the best way to ensure that we don't miss an event. However, it
may be that some of the more unusual filesystems (umsdos? stacking?) call
those functions, leading to a dual-notification. That's not necessarily
a bad thing, but it's suboptimal.
I'm not really keen on the idea of adding these extra test-and-call
patches to each time we call a vfs function. What I'd like to do would
be to stack a notification layer on top of a directory, which would
actually just entail replacing its ->i_op with a shim which notified and
then passed the call on. That would involve remembering the original
->i_op though,and I can't see anywhere convenient to store it.
I'll make a split set of patches available RSN. Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:19 EST