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

[Michael H Buselli]

"John E. Malmberg" said:

> > Right now default_vfs_ops is an external global variable.
> 
> external to what image?

External from code within a VFS module.

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

If I am understanding this correctly, then my proposal should *fix* VFS
modules under OpenVMS so that they can be supported correctly, whereas
without this change the only VFS modules possible are 1) fully
virtualized filesystems, 2) filesystems that disable or fake certain
access functions, or 3) cheats and hacks that bypass the Samba
filesystem access functions provided by default_vfs_ops.  Most useful
VFS modules that I can think of are not in these categories.

> 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".

Doesn't matter.  We aren't doing that.  We're using pointers to the
variables, so they can move around as they like from run to run.

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

We're talking about method one here.  The module name is even specified
in smb.conf!

> 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 true, you should be supporting my idea.  The OLD way leaves an
unresolved symbol "default_vfs_ops" in the VFS module--if you need it,
which I believe most VFS modules out there do.  The NEW way I proposed
has this information passed into its vfs_init() function as a pointer,
so we know where the address is without any symbol resolution at
run-time within the module's code.  Does that make sense?

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

Good point.  I hope people take note of that.  I think they have.

--
Michael H. Buselli
Senior Network Systems Specialist            Abbott Laboratories
Email: busellim at pprd.abbott.com              D472/AP9A-L20
Phone: 847-935-4624                          100 Abbott Park Road
Fax: 847-935-0142                            Abbott Park, IL  60064-3500