lkml.org 
[lkml]   [2005]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: reiser4 plugins
Date
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-06-27 21:45    [W:1.116 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site