Memory Protection

[ekl@sdf.lonestar.org (Evan K. Langlois)]

  Someone has told me that they have MultiTOS 1.04 and an 030 (a Falcon
I think), but they have to rename MiNT to mintnp.prg to turn off memory
protection because if an address is passed to the AES, memory protection
can kill the AESSYS instead of killing the application that called the AES.
I was wondering what the chances are that the AES was being viewed as an
application by MiNT and MiNT was killing the AES for piddling with another
application's RAM.  Is this possible?  I know that a second-hand bug 
description is hard to deal with, especially when it may be the applications
themselves.  

  However, along the same lines, I believe someone was talking about making
pid 001 special like pid 000 (MiNT).  I think this is a good idea.  Killing
MiNT has no effect (like trashing MiNT.000 from desktop), but I can easily
kill GEM on my machine and crash the whole damn system!  By allowing pid 001
global access to memory (so that it could not be killed by memory protection
or such), could possibly solve the problem, but I don't think that is the
right direction to take.

  I do think that pid 001 should not be "killable" from the desktop, and 
if it does die, the system should reboot.  Also, all those errors that say
to adjust the debug level and hit a key always lock up my machine - I'd
rather have it reboot (cold boot) at that time and restart.  I would also
like to reboot every time MiNt exits.  Perhaps an option in MiNT.CNF could
control weither to use the normal errors, or to just reboot?  That would
be an ideal option for plain MultiTOS users.

  On a totally unrelated issue, I think the fork should be non-blocking,
using the slow memory copy method used in MINIX (only so that the call
accomplishes the same on an 030 for a consistent interface), but use the 
MMU on the 030.  Why can't an MMu be added to the 68000?  It should be
possible I think.