On June 24, 2005 11:32, Horst von Brand wrote:
> Hans Reiser <reiser@namesys.com> wrote:
> >
> > 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.

There seems to be a bit of confusion by the OO speak (I was initially confused 
as well -- guess I've spend too much time in broken OO languages recently).  
*grin*  Thinking of interfaces, classes, and objects as a bunch of 1:M 
relationships make it much clearer.

If you start at the bottom, an object (instantiation of a class) has the 
per-object stuff (usually data).  A class (instantiation of a meta-class or 
interface) has the shared object stuff (methods/functions that work on the 
data and static/shared data).  An interface has the shared class stuff (info 
on what the methods/functions and static/shared data are).

A class is a realization of an interface.  An object is a realization of a 
class.  The standard C thing is to have only objects be dynamic at runtime.  
A slightly less common (but very flexible) thing to do is to make the classes 
dynamic at runtime.  This introduces the following C -> OO talk:

-Instances of structures full of data are objects.
-Instances of structure full of function pointers are classes.
-Instances of structure that are a big mix of both are the crossbred 
offsprings of programmers committing OO maintenance suicide by violating all 
the layering (or a savy programmers cleverly saving of one level of 
indirection by caching an object's class' function pointers in the object -- 
depends on your point of view *grin*).

In the Reiser4 FS I believe it goes like this (apologies Hans if I'm wrong).  
The objects are files, directories, etc.  The classes are the plugins.  
Associated with each object is a number (plugin id/class pointer) identifying 
the set of functions (class/plugin) that provides the functions/methods to 
manipulate that object (ids are required because the objects [files, 
directories, etc.] live on the device while the plugins live in memory).

The good thing is that it is very easy to provide new plugins (instances of 
the interface to manipulate the objects).  To create a new new plugin (a new 
class) you just fill in a bunch of function pointer fields in a structure 
(possibly mixing and matching existing functions) and give it a plugin id.  
To use it, you just link appropriate objects (files for file plugins, 
directories for directory plugins, etc.) back to it via the plugin id.

The VFS also has a bunch of OO stuff.  Looking at "include/linux/fs.h", the 
inode structure is mostly data with a few pointers to structures full of 
functions pointers.  Instances of it are most definitely objects.  Instances 
of the associated structures full of functions pointers (inode_operations, 
file_operations, etc.) are most definitely classes (they give an implement of 
their respective interfaces for that inode).  Likewise, instances of 
super_block are objects, while instances of super_operations (and friends) 
are classes.  In short, in Reiser4 FS talk, much of the VFS is done with 
plugins (a plugin being an instance of one of the *_operations structures).

The current merge issue seems to be that apparently (I haven't actually looked 
myself) lots of the VFS plugins that Reiser4 exports are just thunks.  This 
might imply that there are Reiser4 class/plugin interfaces that correspond 
very closely to the VFS class/plugin interfaces (the *_operations).  In this 
case it might make good sense to lift those plugins from Reiser4 to VFS 
plugins.

(If the VFS class/plugin interfaces are subsets of some Reiser4 class/plugin 
interfaces, you could also probably do the lifting.  The additional Reiser4 
class/plugin interface parts could be added to the split off and added to the 
VFS objects via the generic pointer field [i.e., use it to attach the 
additional data and class/plugin pointers to the objects].  As this adds some 
pointer pain for the additional parts you may not really be gaining anything.  
Another possibly approach might be to just extend each of the VFS object 
structures by making them the first entry in more flushed out Reiser4 
specific structures [the Reiser4 code better be doing the allocating in this 
case].  *grin*)

Later!  -T

-- 
 Tyson Whitehead  (-twhitehe@uwo.ca -- WSC-)
 Computer Engineer                          Dept. of Applied Mathematics,
 Graduate Student- Applied Mathematics      University of Western Ontario,
 GnuPG Key ID# 0x8A2AB5D8                   London, Ontario, Canada