[Info-vax] Reloading device drivers on x86-64 VMS

[Bob Gezelter]

On Monday, March 9, 2015 at 5:59:48 AM UTC-4, Jan-Erik Soderholm wrote:
> Craig A. Berry skrev den 2015-03-09 03:23:
> > On 3/8/15 8:38 PM, David Froble wrote:
> >
> >> If you want to install a new version of a sharable image, if it's
> >> compatible with the old version, what does it matter how long before the
> >> old version isn't used?  If it isn't compatible, I think you got more to
> >> worry about than replacing a sharable image.
> >
> > I never said anything about loading a new version. The word was "unload"
> > and in a subsequent post I referenced "a dlclose() or equivalent that
> > actually frees up resources," which, despite the reference provided,
> > seems not to have gotten the point across.
> >
> > Let me try again with an example. A modern web framework might have some
> > dozens of modules or classes or extensions or plug-ins or assemblies or
> > whatever the loadable pieces are called in your language of choice, and
> > each might involve loading one or two or ten shareable images (or more,
> > given the long dependency chains). A web server process might load up
> > one set of these things to satisfy one request, but then need to load an
> > entirely different set to satisfy the next request within the same
> > process and main image activation, so you end up with all of the
> > resources required by both sets allocated at the same time. Under some
> > (but not all) circumstances, it might be desirable to be able to unload
> > one set before loading another, basically undoing everything that was
> > done by LIB$FIND_IMAGE_SYMBOL.
> >
> 
> Probably better to make sure your needed routines are always loaded
> to get the most performance out of your web server applications.
> Just make sure you have whatever resources your environment and
> users requires.
> 
> Is this a real problem today? Or just something "that other
> system" has? And "I want that too!"? Maybe there are other
> things to focus on than some "nice feature"?
> 
> 
> > Which, as hb said, the VMS image activator cannot do. Which I knew,
> > which is why I said it might be a nice feature to add, given that other
> > OS's, such as Linux, already have it (the latter of which I didn't say
> > previously, but seemed obvious in context).
> >

Jan-Erik,

With respect to drivers, the primary usage case is development setup. LOAD/UNLOAD takes seconds; shutdown/reboot (or even HALT/Reboot) takes far longer. Using checkpointed VMs does ease the problem somewhat, but one must be careful. Getting a checkpointed image to the actual state for the test could also be a non-trivial process. 

I am not asking for an API to idle a device, that is a separate issue. However, the ability to UNLOAD/LOAD a device driver (with compatible device structures) would be an aid to development for VSI and third parties). The addition of a unload function entry point (to allow cleanup of driver specific extensions) would also be a good modest improvement, of course with a default of NULL to eliminate the need for modifying existing code.

A simple mechanism to block further ASSIGNs to the device also appears to be not complex on first look.

With regards to shareable libraries, there are two distinguishable cases: linked shareable libraries and dynamically loaded shareable libraries. I do not see a feasible way to generally replace linked shareable libraries on the fly for a running process, as there is no synchronization mechanism. On the other hand, the DLCLOSE idea has some merit, with a proviso: It does not solve the problem of Virtual Address exhaustion.

Allocating and deallocating virtual address space presents a fragmentation problem over time. A DLLOAD/DLCLOSE facility would need careful thought (perhaps reserved expansion pages) to ameliorate the "leap frog" result of releasing and reinstalling ever larger shareable images (e.g., version 1.01 is 100k, version 1.02 is 108k; over long lifespans, the virtual address space will fragment, much like the space on a disk).

- Bob Gezelter, http://www.rlgsc.com