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

[johnwallace4 at yahoo.co.uk]

On Tuesday, 9 June 2015 10:47:33 UTC+1, Simon Clubley  wrote:
> 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

I think what you're perhaps looking for is a current equivalent of
DEC OSF/1. Half a smiley, maybe.

I've done little bits of driver (and other kernel mode) development
on VMS, Linux/ARM, and Linux/x86. And OSF/1. (And VAXELN. But that
is a world of its own).

There is indeed a certain attractiveness to the current Linux device
driver approach you describe. Any concerns I have with Linux are as
much commercial and political as they are technical (e.g. where do
the systemd wars lead, three years from today? Does it matter?).

The portability is indeed neat. For a particular requirement 
involving seriously high speed serial data acquisition, I picked an
interface that was available either embedded alongside an Intel/ARM
IXP425 chip in a small router-size box, or on a PCI card for use in
a different flavour of box.

The initial preference was for ARM but after the development was
nearly finished the box vendor (Moxa) decides they won't tell us
how to reflash the OS to make our changes permanent (oops). The
stuff was all cross-built from Linux/x86 anyway, so...

Change the target from Linux/ARM to Linux/x86, rebuild (no code
changes), plug the PCI interface card into a 2nd hand desktop box,
and carry on. I was impressed - knowing it's theoretically
possible is one thing, showing it can readily be done is another.

In this and many other embedded applications, it's probably
perfectly acceptable to use the 'unload == reboot' approach.
That's not always the case in the server room.