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

[Stephen Hoffman]

On 2015-03-09 01:38:05 +0000, David Froble said:

> Some of these features being discussed are nice, and in some instances 
> perhaps a bit helpful.  Might as well have them, if possible.
> 
> But for somebody running production (whatever that is) I don't see 
> anything discussed so far as very meaningful.
> 
> If you're working on device drivers, you sure aren't working on a 
> production system.  Not on any of mine anyway.

Driver debug, not near production.  But then...  I might then to ask 
myself why these things crash, and why can't there be drivers that can 
be debugged without the current and expected risk of operating system 
crashes.  Something akin to Mach — as was mentioned — might avoid some 
of that, but then Mach has its own issues.   Whether having gazillions 
of cores might actually help with Mach?  Alas, that's all fodder for 
another day.

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

Some folks like the ability to unload and reload code, even when the 
environment is stable.  If you only ever load code, you're leaking 
resources, and leaking eventually blows out some limit.

> A production system is (by my definition) a system running acceptable 
> applications, and there is no reason for emergency updates.  If you do 
> have some required updates, they may require a new executable, or more. 
>   Seems to me that's already covered with current capabilities.

That's one view of production.  For better and for worse, we're 
increasingly headed toward continuous deployment, which is a mental 
shift for many of us.  That usually means a stream of updates arriving, 
rather than big wads on longer schedules.  Some production sites 
already deploy multiple times each day, which can be a bit of a shock 
to the upgrades-once-a-year devops crowd.  VMS is getting 
sort-of-monthly security upgrades mostly for OpenSSL, and this 
situation is only going to speed up, particularly with security, but 
also with other areas of software.  (HP was using a form of continuous 
software deployment with their features-via-patches approach, and I'd 
be surprised if VSI doesn't at least consider incremental or continuous 
deployments; rolling out features as they're ready, rather than sitting 
on what's ready for months or longer.)

For some production environments, rolling out changes might mean that 
reboots are feasible, either individual serves rebooting, or a rolling 
reboot in a cluster configuration.  Or it might mean that a rolling 
process restart is necessary.  For long-running processes that can't be 
shut down — which is the "downside of uptime" problem — that's socket- 
or RPC- or section-style interfaces to some hunk that can restart and 
can reload the code, pending work to allow the process and the server 
to be restarted with minimal or preferably with no service loss and no 
data loss.


—————
[1] For those with Samba servers around: 
<http://blog.trendmicro.com/trendlabs-security-intelligence/samba-remote-code-execution-vulnerability-cve-2015-0240/> 




-- 
Pure Personal Opinion | HoffmanLabs LLC