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

[Bob Gezelter]

On Saturday, March 7, 2015 at 11:49:39 AM UTC-5, Stephen Hoffman wrote:
> 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

Hoff,

Agreed. Although, with respect to "things that will enable revenue", I suspect that the x86 support will require a raft of driver work. Improvements that allow reloads rather than reboots will speed the ability to eliminate bugs in new/modified drivers for x86 (both for VSI and third parties).

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