VFS modules proposed design - WAS Re: Moving 8.3 filenames into VFS - WAS Re: meeting with SUGJ

[Michael Gerdts]

On Mon, Aug 13, 2001 at 08:03:00AM -0400, David Collier-Brown wrote:
> Michael H Buselli wrote: 
> > > One other thing that may be useful is stackable VFS modules.  Suppose I had
> > > two VFS modules: one that did auditing and one that did virus checking.
> > > Under the current model, I would have to decide which one I wanted (or
> > > write a new one that incorporated both feature sets).  If they were
> > > stackable, I could have the functionality of both with no real troubles.
> 
> 	I remember discussing this with Tim, and thought he changed
> 	to a global to allow this...

I don't know how changing it from a share to a global parameter would help.

I am not looking at the code right now, but from looking at it between
2.2.0 and 2.2.1, it looked like the way it was implemented, you could only
have one module handle each call.  When VFS is compiled in you get a list
of functions defined in default_vfs_ops as your operations.  The default
ones behave the same as if you were not using VFS.  The structure vfs_ops
is initialized with pointers to functions for default_vfs_ops.  If you load
a module that does something special with open(), vfs_ops->open gets
changed to be a pointer to the open() call in the new module.  That is,
vfs_ops->open can only reference one open call.

What would be needed is a list (or array, or similar) of functions that are
called for each operation.  That is:

	vfs_ops->open = { vfs_virus->open, audit->open, NULL };

This brings up an interesting question for stackable VFS modules... how do
you handle stacked calls that change state?  That is, if you have a virus
checking open() and an auditing open(), which one should really do the
open?  If it is the first one, does it call the open before or after the
second one is called?  How does each module know whether it is supposed to
really do the open or just be sure that it is OK?

Mike