Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!cornell!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!netnews
From: af@cs.cmu.edu (Alessandro Forin)
Newsgroups: comp.os.mach
Subject: Re: Mach as a Virtual Machine
Keywords: Mach, Virtual Machine OS
Message-ID: <1991Apr19.180259.18834@cs.cmu.edu>
Date: 19 Apr 91 18:02:59 GMT
Sender: netnews@cs.cmu.edu (USENET News Group Software)
Organization: School of Computer Science, Carnegie Mellon
Lines: 83


>>	(3) Execute multiple Operating Systems on top of a single one
>>
>>  I do not believe point (3) per-se is of much
>>value, users just want to run their programs after all.  And the faster
>>they run the happier they are.
>
>     The above belief about the third goal is out of touch with
>operational reality.  Most shops cannot dedicate an entire machine
>to the purposes of installing, configuring, testing, and fixing new
>versions of even the *same* operating system before putting them
>into production use.  Having the ability to run multiple operating
>systems (or multiple versions thereof) concurrently in the same box
>is a real blessing to many shops and their budgets.

The sometimes art-of installing a new version of an OS [e.g relinking the
binaries that the manufacturer gives you to adapt the OS to your specific
hardware configuration] is certainly of much practical importance, but bears
no argument whatsoever on the structural properties of such OS, which is
what I was talking about.

Point (3) refers to the ability to run "unmodified"
OSs binaries on top of each other, not to the ability of running
multiple OS emulators and/or multiple versions thereof.
Which we do routinely and with much gain.

[Practically: IF someone did an IBM V.M. emulator for Mach 3.0 THEN
 the emulator would do exactly the same things the IBM V.M. does, for
 system programmers and for anyone else.]


>>Even in this sense, Mach does not present any more of a "virtual
>>machine" than does any other operating system.  The Mach 3.0
>>facilities don't implement any of the OS *interfaces* that we're
>>currently used to, but they provide a way to implement those
>>interfaces.  In that sense, Mach provides a virtual machine.  So
>>does every other OS, albeit a different one for each OS.

Not all OSs let user programs handle their own syscalls/traps, or let users
handle virtual memory, scheduling, I/O etc etc the way Mach does.
But yes, it is definitely not a Virtual Machine.  Would be quite a mistake
if it were: I could not be posting from this Mach-Vax, now could I ? ;-)


>      The above comment makes it obvious that an attempt has been
> made to make the term "virtual machine" useless by forcing it to
> to mean things it was never intended to mean.  The term *is*, after
> all, virtual *machine*, *not* virtual operating system interface.
> A virtual machine is one that looks to a program like a real machine.
> Even an operating system is supposed to run correctly inside it.

I think my post was quite clear on this.  The term I use is "OS Emulation",
which I personally prefer to "OS Environment" or to "OS Personality"
because I can give it a more concise technical definition.
I could have used "Instruction Set Emulation" to describe what IBM's
Virtual Machine concept is based on, but I was afraid of triggering
much religious reactions and little more understanding.  And besides,
it is a bit restrictive in that V.M. must emulate the 370 I/O system
as well.

>      Terminology in almost any technical field nowadays is getting
> to be so voluminous that people new to a field cannot be familiar
> with all of it.  This results in their reinventing or misusing 
> terms.  Thanks go to Ed Gould here for putting an end to the
> nonsense in this case.

People need new words to understand new things and even new versions of old 
things sometimes.  I do not believe the original poster has attempted in
any whatever way to mistreat the V.M. term [he actually had the citation
right, remember ?].  It is only natural for someone to inquiry what the
difference is between two OSs that appear to do similar things, and wonder
perhaps if the new one does it the same way the old one did, or sort-of.
Note also that the language community has used the same term "Virtual Machine"
extensively for years to denote an hypothetical hardware capable of
executing the (intermediate) output of a language compiler.
The confusion is perfectly understandable.

We all agree Mach is not a Virtual Machine based OS kernel.
But we need to be a bit more precise than that to clarify why
it can provide to users much of the same functionality.  
And faster :-))

sandro-