Re: Virtual Memory

[Christian Lynbech <lynbech@daimi.aau.dk>]

>>>>> "Dancer" == Dancer  <dancer@ozspace.brisnet.org.au> writes:

Dancer> The debate is running in two parts. (1) That it can't be done, (2) That 
Dancer> you would need two kinds of executable to cover VM and non-VM options. 
Dancer> Neither of these is in fact the case. There is no way to solve both 
Dancer> problems quickly, though....part 1 is slow, and part 2 slows down those 
Dancer> machines that already can do VMM.

I do not think that anybody wanted to say that *any* sort of VM
system is principally *impossible*.

But for a VM system to be really usable, it must be transparent to the
programs using it. The issue at hand is not how to write programs that
can exploit a VM system, but how to integrate existing code. And for a
transparent solution, there is no alternative to some sort of MMU
support.

Imagine the mess one would have to go through to change all the many
megabytes of non-trivial GNU code, let alone maintaining it against
updates. And the binary-only programs are of course completely at a
loss.

Even having to recompile programs for a real MMU VM system and make
separate distributions would definitely be a pain, and leave a bunch
of programs behind, but is preferable to not having the option of VM
at all, as I agree that this is something that any serious OS must
have.


------------------------------------------------------------------------------
Christian Lynbech               | Hit the philistines three times over the 
office: R0.33 (phone: 3217)	| head with the Elisp reference manual.
email: lynbech@daimi.aau.dk	|        - petonic@hal.com (Michael A. Petonic)
------------------------------------------------------------------------------