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

[Jan-Erik Soderholm]

johnwallace4 at yahoo.co.uk skrev den 2015-06-09 09:44:
> 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.

This can be exended into the database world. None of our applications
has any "exit handlers" to detach from the database (Rdb). When we
run the application rundown script all detached processes are simply
exited with a STOP <procname>. There are then a number (one for each
stopped process) recover processes running for a second or so to
clean up in Rdb (active transactions and so on). Has worked without
a glitch since 1994.

If we get an unplanned power down/outage, these recover processes
runs after boot instead to clean up.



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