Re: reiser4 plugins

[Horst von Brand <vonbrand@inf.utfsm.cl>]

Hans Reiser <reiser@namesys.com> wrote:
> Lincoln Dale wrote:
> >> Now, if his target is reduced to whether we can eliminate a function
> >> indirection, and whether we can review the code together and see if it
> >> is easy to extend plugins and pluginids to other filesystems by finding
> >> places to make it more generic and accepting of per filesystem plugins,
> >> especially if it is not tied to going into 2.6.13, well, that is the
> >> conversation I would have liked to have had.

> > fantastic - some common ground.
> > any reason WHY there has to be an abstraction of 'pluginid' when in
> > theory VFS operations can already provide the necessary abstraction on
> > a per-object basis?

> VFS supplies instances, plugins are classes.  If a language can
> instantiate an object, that does not eliminate the value of being able
> to create classes.

In OOP speak, VFS is an abstract class, each individual filesystem derives
from this class giving a concrete class, a specific on-disk (or whereever)
filesystem is an object of its (concrete) class. The rest of the kernel (as
a client) doesn't care for the concrete classes, it speaks only (or mostly)
in terms of the abstract class (VFS). And concrete filesystems in turn use
the generic block layer.

> Does it make sense to you now?

No. Sounds jumbled up and backwards. And I don't see how "languages" could
even enter the picture here.

Again: Is there any (sane) way the /existing/ VFS can be used to express
what you want? What are the /minimal/ changes to VFS so each extension can
be catered for in an uniform way across filesystems (anything else destroys
the core idea of having a VFS in the first place!)? What are the required
changes in the clients of VFS (i.e., changes to the core kernel)? What
would be the impact on existing filesystems that /don't/ use new
functionality (this is a lot harder, because it impacts many independent
pieces of code)? What would be required for an existing filesystem to
incorporate it?

When all this is answered, go over the implementation details. But that is
far off still.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

-
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/