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

[Simon Clubley]

On 2015-06-09, johnwallace4 at yahoo.co.uk <johnwallace4 at yahoo.co.uk> wrote:
>
> 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).
>

I don't know if you have ever written any Linux kernel mode code,
but this is exactly why I keep saying the overall Linux kernel
design is a clean design and why I see it as being cleaner than VMS
(at least when it comes to modular kernel structure).

The ability to unload and reload device drivers is a standard and
fully supported capability in Linux. When the user makes a driver
unload request (via rmmod) a routine in your driver is called so
you can clean up behind you using standard Linux kernel mode routines.

It's not just drivers either. For example, in Linux, filesystems
can be placed in kernel modules and unloaded/reloaded so you can
develop a range of modules without having to reboot the system
every time you make a change.

Once you've gone through a kernel module development cycle on both
VMS and Linux, you don't want to have to go back to the current VMS
way of doing things; it's just too cumbersome and slow.

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

For one thing all the architecture specific code is _very_ cleanly
separated on Linux which makes it relatively easy (compared to VMS)
to port Linux to a new architecture.

My best guess is that a Linux port to first boot would be in the
order of months (not years) and you would have something suitable for
field test inside of a year.

>
> 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 :)
>

Exactly, which is why Linux provides a driver specific cleanup routine
to allow the driver to cleanly deallocate resources and idle the device
in question before driver exit.

Of course, what I _really_ want when developing this stuff is a
mainstream microkernel based OS. :-)

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world