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

Jan-Erik Soderholm jan-erik.soderholm at telia.com
Mon Mar 9 06:37:56 EDT 2015


Bob Gezelter skrev den 2015-03-09 11:28:
> 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...
>
> With regards to shareable libraries...

Yes, I was mainly talking about "normal" shareable images.
Such as we all uses in our daily operations.

The driver side is mostly a VSI issue and those quite few that
still does driver development for VMS. I have no opinion on
those, I'm sure VSI can manage without them... :-)

Jan-Erik.




More information about the Info-vax mailing list