[comp.sys.amiga] Re Memory protection for all amiga's

hamish@waikato.ac.nz (03/21/90)

Yo! 
  Alex M.

 I wish to clarify something. The MMU doesn't necessarily have to provide
seperate address spaces for each task. It can provide simple write protection
for memory. This would enable code segments to be write protected and even
local data segments (pages) that didn't have to be read by other tasks.

The code segments could be always write protected & write protection turned
off on the data for the currently running task.

  Look Ma...   Memory Protection.

When the MMU is reset it provides 1 mapping ie logical = physical. No write
protection at all. Keep the 1=1 & add write protection.


Hamish Marson.

hopp@thor.acc.stolaf.edu (Eric D. Hopp) (03/28/90)

In article <248.26077b42@waikato.ac.nz> hamish@waikato.ac.nz writes:
>
> I wish to clarify something. The MMU doesn't necessarily have to provide
>seperate address spaces for each task. It can provide simple write protection
>for memory. This would enable code segments to be write protected and even
>local data segments (pages) that didn't have to be read by other tasks.
>
>The code segments could be always write protected & write protection turned
>off on the data for the currently running task.
>
>  Look Ma...   Memory Protection.
>
>When the MMU is reset it provides 1 mapping ie logical = physical. No write
>protection at all. Keep the 1=1 & add write protection.
>
>
>Hamish Marson.

I've been following the resource tracking / memory protection thread
for some time now.  High time I speak up.

As I see it, crashing far too often is one of the Amiga's biggest
faults.  Using an MMU as Hamish outlined above--having all memory
execept that belonging to the current task and any MEMF_PUBLIC stuff
write protected--would make most errant memory writing recoverable,
rather than fatal.  Surely exec.library can be made smart enough to
sense the presence of an MMU.

As for resource tracking, (an the corollaries, the ability to KILL a
task and the automatic returning of all unreturned resources upon
exiting), I see no good reason for not putting it in soon.  All that
is needed is a list of resources used in the task structure--any
library or device granting use of a resource would make an entry in
this, and at exit time they could be called to handle to reclaiming of
that resource.

							-eric hopp
							 hopp@stolaf.edu