Re: reiser4 plugins

[Christoph Hellwig <hch@infradead.org>]

On Sun, Jun 26, 2005 at 04:42:35PM -0700, Hans Reiser wrote:
> >I'm a bit confused about what you're saying here.  What does the 'vector'
> >in all these expressions mean?
> >  
> >
> Was your word, I thought, for the *_operation structures.

We tend to use the term operation vectors, yes.  But that's a different
terminology that doesn't mix up very well with the OO terminology.

> So, rather than having a hierarchy, in which we first select filesystem,
> and then select plugin, VFS should treat each plugin as though it was a
> filesystem, if I understand you.

Kinda.  The VFS doesn't have knowledge about what constitutes a file
system driver, we register filesystems only to know what routine to
call in on a mount with a particular filesystem type - the structure that
does describe a filesystem (struct file_system_type) thus is very small.
Starting from there the filesystem has always been able to use different
methods for different objects (that's something very different from the
vnode-based VFSes in the other UNIX variants).  

> Plugins and pluginids continue to exist
> with the exact same functionality, we just eliminate a function
> dereference for the *_operation structures. Let's see how it codes up in
> its details.

For the file and dir plugin that's pretty much that case.  What's more
problematic is your security plugins.  With LSM we alredy have an
infrastructure to provide pluggable access control.  If there actually
was an implementation of "security" (it's actually access control) for it
besides the default unix permission one it should move to an LSM.  You
could even make your lsm part of the reiser4 module and poke into reiser4
directly from a technical point of view.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/