On June 24, 2005 11:32, Horst von Brand wrote: > Hans Reiser <[email protected]> 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 ([email protected] -- WSC-) Computer Engineer Dept. of Applied Mathematics, Graduate Student- Applied Mathematics University of Western Ontario, GnuPG Key ID# 0x8A2AB5D8 London, Ontario, Canada
Attachment:
pgpr2GVToNEZX.pgp
Description: PGP signature
- References:
- Re: reiser4 plugins
- From: Horst von Brand <[email protected]>
- Re: reiser4 plugins
- Prev by Date: Re: 2.6.X not recognizing second CPU
- Next by Date: Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
- Previous by thread: Re: reiser4 plugins
- Next by thread: Re: reiser4 plugins
- Index(es):
 |