> 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
-
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:20 EST