Re: [MiNT] virtual memory

[Michael Schwingen <rincewind@discworld.dascon.de>]

On Tue, May 02, 2000 at 01:03:28PM +0200, Guido Flohr wrote:
> 
> I think Michael hit the wrong button and sent his reply to me not to the
> list.  I leave his quotes untouched.

Oops - right, thanks.

> > About the relocations: as a first step (without ELF), I have two ideas:
> >  - let the text segment of all programs in the new format start at virtual
> >    address 0 - that way, we do not need to fixup anything, and such a
> >    program could also work on an old TOS system. However, we do not get
> >    access to ST-RAM anymore (at least not with virtual==physical addresses).
> 
> But the first pages of physical RAM contain the "system variables", the
> cookie jar, ...

Right. That would not matter for really clean programs, but in general this
makes this a bad idea.

> Why do you want to extend the old program format? I think we agree that
> programs that benefit from a VM extension would not run on plain TOS or
> Magic.  With VM we could simply take over the ELF linker for m68k Linux
> and prepare the kernel to be capable of running these binaries.  I only
> speak of the binary format, not of binary compatibility.  In other words,
> we still have "MiNT instructions" (not Linux instructions) but the program
> layout could be the same as for Linux, mainly to reduce the amount of work
> necessary for the binutils.

Modifying the PRG format is a quick-and-dirty solution to test this out -
you can take a normal program and re-link it to the new start address as
long as the data segment is not write protected.

In the long run, I agree that ELF or some similar format is the way to go.

> I am quite familiar with the sources of the GNU binutils and IMHO the
> biggest amount of work will lay there, i. e. provide the necessary tools
> and functionality to /build/ programs, not to /run/ them.  The
> modifications in the kernel necessary for supporting a new binary format
> (and we need that in any case) are relatively small compared to the
> efforts for a linker, debugger, symbol lister ...  I think it is therefore
> wise to adapt the binary format (and all these tools) from other systems
> and ELF seems to be the first choice.

What I was suggesting was just a way to circumvent that to get the whole
thing started with minimal effort: we can generate TOS binaries with the new
linker, so it requires just a new linker script to align the sections and a
flag in the header.

> But I still haven't understood how "old" programs will run in a VM
> kernel.  These programs will possibly access system variables directly,
> they will peek into each other's memory, they will read and insert entries
> in the cookie jar and do other bad things.  Would it be possible to
> proceed like this:  The kernel spawns at boot time a super-process that
> runs in an address space that looks identical to the current memory
> layout.  "Old" programs will run in this address space and can do what
> they want there.  If they make the system crash there will still be a
> chance to shut down the system in a clean way, provided that the shutdown
> tools are "clean".

That might work. However, to be useful, a program requiring such a framework
will dig deeply into the memory, which means we need to provide a real,
working version of TOS variables - I don't think we can generate a working,
virtual copy inside some sandbox environment.

> Yet, I still don't see how AES and VDI traps could be handled.  For
> example USERDEF objects contain the address of a callback routine and we
> need a way to switch the address space then.  Maybe this could be managed
> if the "clean" address space starts at a relatively high address like 1
> GB.

I think N.AES handles this by running objc_draw etc. in user context (ie.
not from inside the AES trap). After all, the object routines of the AES can
be considered as a library which is part of the program, not the system
(protection-wise).

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen