Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!oliveb!amiga!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: MMUs and Re: inconsistent gadget function parameter ordering
Message-ID: <6752@cbmvax.UUCP>
Date: 3 May 89 17:44:37 GMT
References: <7989@killer.Dallas.TX.US>
Organization: Commodore Technology, West Chester, PA
Lines: 44

in article <7989@killer.Dallas.TX.US>, elg@killer.Dallas.TX.US (Eric Green) says:

> But don't expect miracles. As I said, the MMU was intended for running
> Unix. As such, it's just fine for doing virtual memory, and if I had a
> 2620, I'd be working on hacking it this very moment (;-). But it was
> not intended for AmigaDOS. AmigaDOS assumes one big shared address
> space, with all the processes living in peace together in that big
> shared address space. The MMU can make that big address space even
> bigger. But it still can't keep process A from tromping on process B's
> data, at least not without a big horrendous slow kludge.

Well, I'm not sure how horribly kludgy it would get or not.  In order for per-
task protection to work, you'd have to have an MMU table, or at least a part
of one, added on to the context information for each task.  I think the best way
for this to work would be to have PUBLIC and PRIVATE memory in different
physical locations.  When a task got swapped in, it would have it's table for
PRIVATE memory replace that of the prior task, while PUBLIC would be the same
for all tasks.  This would still be a linear address space, and would count
on program's properly allocating this PUBLIC and PRIVATE memory (eg, I
doubt that MEMF_PUBLIC is respected well enough for that to be sufficient).
In any case, it's MUCH more complicated than just adding virtual memory,
as you stated.  UNIX makes the job of protection much easier by generally
not having shared memory, having each task start at the same logical memory
location, and having all memory allocations for each task contiguous.  

>      (But does the MMU support making pages execute-only? If so, at
> least process A can be kept from tromping on process B's code).

Pages can be read-only; not sure if there's a way to make them execute-only.

As far as the MMU in the 68030, or the 68851 MMU go, they're about as
flexible as a paging MMU gets.  UNIX happens to work very well with paging
MMUs, but that's doesn't imply that these MMUs are only suitable or 
decent for UNIX.  Though as I said before, I suspect anything like protection
will require OS support to work well at all.

> |    // Eric Lee Green              P.O. Box 92191, Lafayette, LA 70509     |
> |   //  ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg     (318)989-9849     |
> |  //    Join the Church of HAL, in worship of all computers  with          |
> |\X/   three-character names (e.g. IBM and DEC). White lab coats optional.  |
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession