🚀 go-pugleaf

In article <8905260140.AA04445@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes:

   Deven Corzine <deven@rpi.edu> writes in
   Message-ID: <DEVEN.89May24025106@daniel.rpi.edu>

   > Fine.  But the RKM's say interrupt code and data MUST be in
   > MEMF_PUBLIC memory.  Why?

   Interrupt code might be called up by any task in the system. Thus
   the Exec and the MMU will think that the code executed is part of
   the calling task. If that code and its data can are not accessible
   through the MMU by what the Exec thinks is the current task, you
   get a priviledge violation error.

Interrupt code is not "called up" by any task in the system.  Yes,
interrupts can occur while any task is running.  But, there could be a
separate MMU context for interrupts...  The problem does NOT lie with
what *Exec* thinks the current task is, but with what the *MMU* is
using for the current context.  It's not inconceivable to
context-switch for interrupts, though the overhead may well be such as
to make it impractical.

   > And yes, virtual memory will have far less damaging effects
   > than memory protection, with the design of the operating system -- the
   > message passing mechanism, in particular.

   I believe I already demonstrated why the contrary is true.

Arguments can certainly be entertained by both sides, but the fact
remains that Exec was designed using the model of a *single* address
space for all tasks, with any task being able to access the memory of
*any* task.  This is particularly evident in the message-passing
mechanism, though it could obviously be patched so as to copy messages
or perhaps to switch the protection of the message region to the
recipient until the ReplyMsg...  But if a program passes a pointer to
its own buffer to another task, protected memory will break that sort
of setup.

Virtual memory, on the other hand, modifies the model mostly
transparently.  The only places where trouble arises is when something
*must* be in physical memory.  (interrupts, screen memory, etc.)  The
address space can be transparently expanded and manipulated without
breaking as much.

I stand by my statement.

Deven
--
shadow@[128.113.10.2]   <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847
shadow@[128.113.10.201] <shadow@acm.rpi.edu>  2346 15th St.    Pi-Rho America
deven@rpitsmts.bitnet   <userfxb6@rpitsmts>   Troy, NY 12180-2306  <<tionen>>
"Simple things should be simple and complex things should be possible." - A.K.