[Info-vax] Modular VMS, was: Re: Prism/Pillar, was: Re: inertia or fundamentals about langages?

[Simon Clubley]

On 2019-05-29, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> On 2019-05-29 12:21:11 +0000, Simon Clubley said:
>
>> On 2019-05-28, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>> 
>>> The production ports of OpenVMS for Alpha and Itanium were interesting  
>>> and technically complex and challenging in various ways, but haven't 
>>> particularly diverged from the design and organization of the 
>>> progenitor VAX modular kernel.
>> 
>> Should that be monolithic, instead of modular ?
>> 
>> I wouldn't exactly call the VMS kernel modular, especially by today's 
>> standards.
>
> Donno.  I've always called it "modular", though "modular monolithic" 
> might be closer to current terminology.
>
> While the OpenVMS kernel uses a monolithic address space, the 
> organization of the kernel itself is not monolithic and the various 
> pieces of the kernel are dynamically linked together during and 
> variously after bootstrap.
>

While the VMS kernel may be organised in that way, it is still a
monolithic mass of code as far as anyone actually using it is concerned.

There's no way to reload device drivers for example.

The XQP cannot be extended by the end user so they can't plug in
new filesystems, either in the kernel or within a process.

You know the following, but for those who don't, take a look at the
examples of what you can do in Unix-land:

https://en.wikipedia.org/wiki/Filesystem_in_Userspace

The process level option (ie: the ACPs) come across as being horrible to
create and integrate into the rest of VMS and the process is undocumented.

The terminal driver code is so yucky and unchangable that you can't even
edit lines that wrap a line boundary. In 2019/2009/1999, that's crazy.

You can't swap out the system supplied shell (DCL) with another shell
supplied by the user due to the heavy integration of DCL into the VMS
way of doing things and due to the total lack of documentation about
how to write a replacement login-level shell.

[snip]

>
> If this discussion follows one of the usual courses, there would 
> usually soon be some confusion posted around macOS and the XNU kernel. 
> "XNU is a hybrid kernel, containing features of both monolithic kernels 
> and microkernels, attempting to make the best use of both technologies, 
> such as the message passing ability of microkernels enabling greater 
> modularity and larger portions of the OS to benefit from memory 
> protection, and retaining the speed of monolithic kernels for some 
> critical tasks."
> https://en.wikipedia.org/wiki/XNU
>

Nice as it would be, I'm not looking to replace VMS with a microkernel.

I just want VMS to have the same level of module based flexibility that
other current monolithic kernel designs have.

When you only know VMS, then I suppose everything looks ok and you don't
see a problem. When you know other operating systems however, that's when
you _really_ see what VMS is missing.

Even today, VMS still has leading features, such as VMS clustering.
They can easily be hidden however by all the things you trip over or
otherwise miss having available when you are using VMS.

BTW, one final thought. Sooner or later, VSI is going to have to tackle
the problem of trying to sell VMS to new sites in order to continue growing.

When you look at VMS as it stands today and in the future, what do you
tell those potential new sites to persuade them to have a go at
evaluating VMS ?

What do you tell them when they ask why they should look at VMS instead
of other operating systems they are more familiar with and which have
features they are familiar with ?

Simon.

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