[Info-vax] VSI: "Official 8.4-1H1 Launch"

[johnwallace4 at yahoo.co.uk]

On Tuesday, 9 June 2015 04:25:28 UTC+1, JF Mezei  wrote:
> On 15-06-08 20:02, David Froble wrote:
> 
> > But really, what is the demand for unloading drivers?
> 
> Applying updates to system without requiring reboot. (and services
> stopping during reboot)

But I thought the 'modern' way was to abandon any interest in extended
uptimes and just accept that downtime and rebooting is necessary for
such things, and find some other way of avoiding service disruption,
the simplest of which might be to just have a frequent scheduled
reboot.

Sticking with 'unload == reboot' would appear to keep some aspects
of the OS a little simpler, though actually many of the aspects
which enable unloadable kernel components are probably aspects of
good design practice anyway (clean interfaces, clean resource
allocation and deallocation, few/no unwanted cross-couplings, etc).

That design cleanness has benefits of its own, but the re-work
involved may not be attractive when the effort needed and the risk
involved may outweighs the benefits.

After all, how many people when writing some random application
go to the trouble of ensuring that it does its own pre-exit
cleanup rather than leaving it as something for the OS to do?
Even on VMS where exit handlers and condition handlers and so
on are as old as the hills and work in a documented and largely
language-independent way, how many people (need to) bother? But
the framework is there for those who need it, which is great.

In some ways that's the same kind of thinking as is involved in
the unload vs reboot discussion, except with per-application 
scope rather than per-system scope. Sometimes you do need to
think about an explicitly ordered cleanup and shutdown. Often
when an application exits, it's simpler (and just as safe) to
let the OS clean up on behalf of the application. But sometimes
that may not be the case.

With kernel modules, the chances of the OS being able to do a
'default cleanup' and get it right are probably small. The 
chances of leaving an inconsistent and unworkable kernel
afterwards are probably not small, but what's the worst that
could happen, probably just a bluescreen :)

TLDR: Unloadability is a nice goal. If an OS framework can 
support it from day 1, then why not. But it's hard to
evaluate the usefulness and cost-effectiveness of
retrofitting it into an existing OS, especially where other
aspects may have a more pressing need of attention.

It depends.