In message <10005212204.ZM71494@rlyeh.engr.sgi.com>, "Rusty Ballinger" writes:
> > 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'd like to see the same thing (for files as well as directories). The
> existing imon patches (http://oss.sgi.com/projects/fam/imon.txt) also work
> by adding notification in sys_write etc., but that seemed too lame to post
> on lkml because it means operations on any file have to pay the price for
> a service which is used on relatively few files.
>
> If modules could easily replace ->i_op (preferably without stomping each
> other), you could load modules which did whatever they wanted in response
> to various operations on specific inodes (logging? encrypting data?
> preventing/redirecting operations?), and performance would only be affected
> for those inodes who were deliberately being fiddled with. Not only that,
> but the rest of the filesystem code wouldn't have to know about it, and
> wouldn't get cluttered up with "now send SIGIO... now notify imon..." etc.
> after every operation.
>
> You could do a lot of neat stuff with that. (Is there already a way to do
> this?)
>
> --Rusty
What you're describing is called stackable file systems, which I've created
under Linux. I have an encryption f/s, compression f/s, and several other
samples---all built on top of "generic" stacking templates. See
http://www.cs.columbia.edu/~ezk/research/fist/
Erez.
-
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:23 EST