Re: [MiNT] virtual memory

["Guido Flohr" <gufl0000@stud.uni-sb.de>]

Hi,

I think Michael hit the wrong button and sent his reply to me not to the
list.  I leave his quotes untouched.

On Fri, Apr 28, 2000 at 08:21:58PM +0200, Michael Schwingen wrote:
> On Thu, Apr 27, 2000 at 07:39:59PM +0200, Guido Flohr wrote:
> > 
> > Nice, but it wouldn't work out of the box.  First, it requires the text
> > segment to be read-only (I doubt that the many programs where data == 0 would 
> > like your idea) and the current binary format is not suitable for it
> > because it would require to re-fixup the text segment whenever the pages
> > are reloaded into memory.  Either the kernel has to cache the fixup table
> > or it has no reload it too.
> 
> Damn - right.
> 
> > With virtual memory we should really think about a new program format like
> > ELF (but implement VM first ...).  Maybe we can overcome some
> > compatibility problems by simply demanding new standards for programs in
> > that new format.  For example we could forbid certain "dirty" operations
> > for these programs, we could "undefine" currently documented addresses
> > (that could solve the Milan video ram problem).
> 
> Yes. I think we would need at least a flag to indicate that a program is
> 'clean', and that could also indicate that the text-segment may be
> write-protected and that data and BSS start on page boundaries.
> 
> Such a program would then have a write-protected text segment, and the whole
> 4GB (minus global and kernel memory) address space.
> 
> 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, ...

>  - link the program so that it is not based at address 0 (which is the case
>    with normal PRGs), but at $01000000 or some other convenient address, and
>    map the text segment there. This also removes the need for fixups, but
>    these programs will not work on TOS anymore.

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.

ELF programs should then be "clean" according to our new standards,
i. e. page-aligned, text segment read-only etc.

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.

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".

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.

Ciao

Guido
-- 
http://stud.uni-saarland.de/
Send your spam to president@whitehouse.gov and your replies to
mailto:guido at freemint dot de