[Info-vax] VMS port to x86

[John Wallace]

On May 31, 10:08 pm, JKB <j... at koenigsberg.invalid> wrote:
> Le Thu, 31 May 2012 13:56:36 -0700 (PDT),
> John Wallace <johnwalla... at yahoo.co.uk> écrivait :
>
>
>
> > On May 31, 9:28 pm, JKB <j... at koenigsberg.invalid> wrote:
> >> Le 31 May 2012 09:35:17 -0500,
> >> Bob Koehler <koeh... at eisner.nospam.encompasserve.org> écrivait :
>
> >> > In article <slrnjse7if.ul.... at rayleigh.systella.fr>, JKB <j... at koenigsberg.invalid> writes:
>
> >> >>        That's why VMS should not be ported on x86, but on top of a real
> >> >>        microkernel. L4 is a good candidate as it is compact and simple. If
> >> >>        you want to port your OS on another processor, you only has to port
> >> >>        microkernel (and toolchain).
>
> >> >    Port VMS to the hardware and you get the behaviour of VMS.
>
> >> >    Rewrite the VMS kernel and APIs to sit on top of a micro-kernel and you
> >> >    get some other behaviour, limitted by what the micro-kernel can do.
>
> >> >    There are a great many applications that won't care.  And some that
> >> >    will.
>
> >>         And why ?
>
> >> --
> >> Si votre demande me parvient sur carte perforée, je titiouaillerai très
> >> volontiers une réponse...
> >> =>http://grincheux.de-charybde-en-scylla.fr
>
> > Because most user mode applications mostly don't (or at least
> > shouldn't) care about the exact behaviours of the underlying OS? Such
> > user mode stuff probably already works fine in one of the various
> > readily available VAX or Alpha emulators, subject to the usual
> > commercial considerations, so a DIY VMS is not necessarily of major
> > interest. Not necessarily a bad idea, but not necessarily attractive
> > to IT departments and end users who just want a way to run routine VMS
> > applications.
>
> > On the other hand, VMS would happily let you run complex kernel-mode
> > and/or real-time stuff on the same box that was supporting interactive
> > and batch users. It may not always have been a bright idea to do that,
> > but it usually worked. Sometimes these things came to depend on
> > behaviours that weren't formally documented but were predictable and
> > reliable; sometimes that kind of dependency happened even without the
> > interactive and batch users.
>
> > If micro[kernel]VMS doesn't demonstrably have those same reliable and
> > predictable behaviours, it is probably of no interest to this class of
> > application. There may not be lots of people in this class, but if the
> > rest of the users are happy with an emulator...
>
>         I don't understand why you think that a microkernel couldn't offer
>         all capabilities required by OpenVMS. Don't forget that DEC has
>         ported VMS (kernel and some features) on Mach a long time ago.
>
>         JKB
>
> --
> Si votre demande me parvient sur carte perforée, je titiouaillerai très
> volontiers une réponse...
> =>http://grincheux.de-charybde-en-scylla.fr

I've been around long enough to remember Mach and Chorus, thank you,
though I'd forgotten about VMS on Mach (Tru64 got more publicity on
that front). I do understand (at some level) how a microkernel can in
principle on paper offer all the necessary capabilities for user mode
non-time-sensitive stuff with no dependence on OS internals.

I'm saying that what *some* VMS customers expect is more than that;
they require specific behaviours, such as specific responses within
specific timeframes of specific events. These may also include bits of
software that have carnal knowledge of VMS internals, especially
kernel internals, and behaviours. Maybe reproducing those behaviours
is not necessarily impossible with a microkernel, but nor is it as
easy as reproducing user-visible behaviour.

Readers who refer to the DEC-written paper on the VMS on MACH
experiments [1] will find phrases like "provides for execution of
existing non-privileged VMS binary images." and "develop a model of
VMS that includes the functions, policies, and mechanisms needed to
support the execution of VMS non-privileged (user) images." Looking
good so far, within the stated constraints.

And then we see "Certain mechanisms are no longer used within our
model but are preserved for use by VMS applications (sometimes with
changes that may be visible to applications)." And "The scheduling
effects of VMS spinlocks are not maintained by [micro[kernel]VMS
replacement]". And "It is not feasible to reproduce the VMS scheduling
policies using Mach". And so on. Suddenly the behaviours aren't
necessarily compatible, for some classes of application.

Obviously I'm being very selective. For the bigger picture, read the
whole paper.

Maybe some of these considerations are the same kind of VMS internals
stuff that would be considered when moving from VAX to Alpha (one I
didn't quote referred to stack frame usage, for example). The vast
majority of applications being ported didn't need to worry about these
things. Some did, and that's where life got interesting.

Basically, like I was trying to say, user mode stuff may well "just
work" on top of a microkernel. Stuff that has dependencies on non user
mode stuff, on OS internals, may see different behaviours under
micro[kernel]VMS.

No need to take my word for it. But please dear reader, if you're
interested (and this is interesting stuff, honest), see what the real
experts had to say about it.

"tl;dr" version: simple stuff is simple, and you can simply do it
today in a simulator. Hard stuff is harder, and there are no
guarantees it can be done with the accuracy required either in a
simulator or with a microkernel. A rewrite (partial or complete) of
the application may be required.

Have a lot of fun.

[1] http://www.sture.ch/vms/Usenix_VMS-on-Mach.pdf