Path: utzoo!attcan!uunet!pyrdc!grebyn!ckp
From: ckp@grebyn.com (Checkpoint Technologies)
Newsgroups: comp.sys.amiga
Subject: Re: Memory Protection
Summary: So much would break that they don't dare
Message-ID: <14037@grebyn.com>
Date: 19 Nov 89 18:01:25 GMT
References: <807@trlluna.trl.oz> <8911180206.AA22553@en.ecn.purdue.edu>
Reply-To: ckp@grebyn.UUCP (Checkpoint Technologies)
Organization: Grebyn Timesharing, Vienna, VA, USA
Lines: 42

In article <8911180206.AA22553@en.ecn.purdue.edu> bevis@EE.ECN.PURDUE.EDU (Jeff Bevis) writes:
>In article <807@trlluna.trl.oz>, aduncan@rhea.trl.oz.au (Allan Duncan) writes:
>>From article <410@mohawk.cs.utexas.edu>, by bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End):
>>
>>What is MEMF_PUBLIC for then?
>>
>This flag specifies that you want memory (chip or fast) which is 
>guaranteed not to be swapped out or become unavailable to all processes all
>the time.  You will want this type of memory for I/O operations (buffers,
>things the OS will look at).  It's not of any consequence to ignore this
>flag NOW.  But when Amiga/VM arrives -- oh, the software that will break!
>So be sure to use it when appropriate.
>
    If Commodore's VM AmigaDOS actually broke programs that don't
properly use MEMF_PUBLIC, then almost nothing would work. MEMF_PUBLIC
supposedly means that the memory so alloced can be shared; and
conversely, any memory which is not so allocated cannot be shared.
There are many many programs which allocate structures which must be
shared, but don't. See, there has been no way to enforce MEMF_PUBLIC's
proper use. Enforcing MEMF_CHIP was impossible until fast RAM become
available (at which point some programs broke; most notable, perhaps,
Deluxe Paint). The only way to enforce MEMF_PUBLIC's proper use is with
an MMU, and most Amigas don't have one, and all Amiga's don't use it. So
now that MEMF_PUBLIC's had all this time to be abused, to begin
enforcing MEMF_PUBLIC would cause a disaster.

    In my own humble opinion, I think Commodore needs to support VM with
two different approaches: first, the one they took, by defining the
MEMF_VIRTUAL bit and publishing the rules for it's use. Not using it is
not a crime (punishable by breaking), but mis-using it will be.

	The second approach should be to define a new, protected-mode
environment in which protected programs will run. Both environments
should be able to cohabit under Exec. When a protected program crashes,
it's resources would be reclaimed and it would be removed cleanly from
the system. Of course, when an unprotected program crashes it must
still result in a guru (oh, sorry; System Message) and reboot, because
that's the nature of an unprotected system; and protected mode programs
would come down with it.

Richard Krehbiel, with Checkpoint Technologies
(Working on a new .sig! Be patient.)