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

[David Froble]

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.

I don't think anyone is disputing your claims.  And yes, being able to 
unload drivers and such is a nice feature.  But look at it from a 
practical perspective.

What does it actually gain you with respect to solving a business or 
other problem?  I don't think it's a whole lot.  Not saying it should 
not be a capability, just looking at the value of it.


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

I'm focusing on the word "develop".  For a developer, yes, I've written 
before that it might be a nice thing to have.

I can also imagine some patches that could be set up to apply without a 
re-boot.  Nice feature.  Patch in the middle of the day instead of 
waiting until the middle of the night.

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

Well, I think you're missing at least one thing.  I'm guessing Linux is 
implemented 100% in C, and if you're porting to something with a C 
compiler, that is one big task that you don't have to do.  VMS is not 
100% C, and I for one think that's a good thing, and multiple compilers 
must be ported right up front.  Now let's look at those compilers. 
Before you're done you're going to need them anyway, because some 
customers will need them.  (What good is a port if no customers will be 
able to use it?)  So porting Linux and porting VMS really are two 
separate types of tasks.

I'll also point out that the multiple languages supported on VMS is one 
of the strengths of the OS.


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

See above ...

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

I'm sure that the same capability could exist in VMS.

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

Yes, we know, and I for one am still not sold 100% on that concept.