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

[Stephen Hoffman]

On 2015-03-07 16:30:18 +0000, Bob Gezelter said:

> In doing extensive driver-level work on RSX, the ability to quiesce and 
> reload a driver without a reboot was vital to achieving progress. It 
> always had the limitation that you needed a quiescent device, the data 
> structures were compatible, and there was always the degree of risk 
> that a crash could ensue. That said, it was extremely helpful at 
> speeding progress.

This ties back to the available enabling APIs and tools, and to the 
general state of OpenVMS itself.  Driver-quiescing APIs here.  APIs for 
much more granular power management and interrupt management from 
another thread.  Device removals have have been requested a few times 
over the years, and the driver-unload request here is a form of that 
classic request.   APIs for the application coordination with backups 
for yet another recent thread.  Then there's that the various APIs are 
fragmented or missing or down-revision, such as the lack of an 
integrated database capabilities past RMS or the ad-hoc and fragmented 
packaging of pieces such as the I18N bits or the lack of an integrated 
web server, the lack of an IDE for OpenVMS or APIs and documentation to 
assist with third-party IDEs for OpenVMS, and that's before discussions 
of the turn-around inefficiencies and delays with getting patches and 
updates for OpenVMS processed and available such as the 
usually-down-revision OpenSSL bits and the associated and more general 
issues around getting patch notifications distributed and getting the 
patches installed in a vastly more efficient fashion, and before that 
some folks are using the same software kit for both installations and 
factory-installed software (FIS) and with vastly faster updates for the 
kits, and....  well... {inhale} VSI has a whole lot of work ahead of 
them, and that's just to keep track of the feature lists and feature 
requests.  Then the important question being what VSI can make (more) 
revenue from, though going short-term on that is usually not without 
long-term costs, and the related discussion involving where else the 
existing and potential new customers can go for these and other 
capabilities that they might want or need.  Interesting times, eh?


-- 
Pure Personal Opinion | HoffmanLabs LLC