VFS modules proposed design - WAS Re: Moving 8.3 filenames into VFS - WAS Re: meeting with SUGJ

[John E. Malmberg]

On Wed, 1 Aug 2001, Michael H Buselli wrote:

> Michael Gerdts said:
> 
> > One other thing that may be useful is stackable VFS modules.  Suppose I had
<SNIP>
> I thought that this would be a good idea as well.  From the perspective
> of being within the VFS module, could it be as simple as replacing the
> function pointers in default_vfs_ops with function pointers to the VFS
> module in the next layer down?
> 
> Right now default_vfs_ops is an external global variable.

external to what image?

>  It would
> probably be better to pass a (const struct vfs_ops *) into the
> vfs_init() function within the VFS module and expect the coder of the
> VFS module to save the pointer to that struct vfs_ops in a file-local
> global variable.  At initialization the different vfs_init() fuctions in
> each VFS module would be called with the lowest VFS module getting the
> true default_vfs_ops structure, the second lowest getting the return
> value of the first after it was modified appropriately to fill in the
> NULLs, and so on.

For me to build a plugable module on OpenVMS, it must not use symbols
resolved from it's caller.  All addresses not known to the plug-in at
the time it is linked as a shared image, must be passed to the module by
the caller.

It is almost impossible for me to work around that requirement.


The very much preferred way for a caller to access data stored inside
of a plug-in is by use of a function that returns a pointer, and not
by using direct access to an external variable.

Providing external variables directly from a shared image is doable, it
just introduces maintenance issues in making sure that those variables
always appear at the same "address".

I have two ways of causing a plug-in to be dynamically loaded.  Method
1 is the dlsym() api, where the plug-in is not always needed.

Method 2 is I can link in a stub shared image with the same entry points,
and then at the time I run the image, I can specify which shared image to
replace the stub.  Sort of like using a symlink.

In OpenVMS, all symbols must be resolved when a shared image is linked.
If they are external, they must be in another shared image that was
previously linked.


If all libraries are built with these rules in mind, it is trivial to make
them into shared images on all platforms, not just OpenVMS.

There is a major advantage besides a much faster total LINK time, and less
total disk space and physical memory used for the end product.

That is the libraries can be swapped out at run-time to try out a new
patch or procedure with out having to relink and possibly recompile the
world.


-John
wb8tyw at qsl.network
Personal Opinion Only