In message <20000521121830.X28590@xxxxxxxxxxxxxxxxxx>, willy@xxxxxxxxxxxxxxxxxx
writes:
> On Sat, May 20, 2000 at 03:31:29PM -0400, Erez Zadok wrote:
[...]
> > - 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.
My stacking code, as well as other F/S, calls the vfs_* functions. In a
stacking environment, you may cause duplicate signals sent for the same
event. It might be better for you to do this work in a stackable f/s, from
which you can control the lower layer somewhat, and avoid the duplicate
signals that way.
BTW, this recursive behavior is a problem currently with ->permission, which
I hope will be fixed with a proper vfs_permission() function.
> 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.
Replacing an existing ->i_op is ugly, and can lead to all kinds of problems,
but it's doable. My stacking code doesn't replace existing ->i_op vectors,
but rather create a new one for operations that know how to go from one
layer to another. (We store lower objects, such as inodes, in the private
field of the struct inode.)
Erez.
--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx
|