Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!unmvax!indri!csd4.milw.wisc.edu!leah!rpi!rpi.edu!deven From: deven@rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: MEMF_PHYSICAL? Message-ID: Date: 26 May 89 07:47:02 GMT References: <8905260140.AA04445@jade.berkeley.edu> Sender: usenet@rpi.edu Organization: RPI Public Access Workstation Lab, Troy NY Lines: 52 In-reply-to: 451061@UOTTAWA.BITNET's message of 26 May 89 01:35:50 GMT In article <8905260140.AA04445@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: Deven Corzine writes in Message-ID: > 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] Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet Troy, NY 12180-2306 <> "Simple things should be simple and complex things should be possible." - A.K.