Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!rpi!rpi.edu!deven From: deven@rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: MEMF_PHYSICAL? Message-ID: Date: 19 May 89 09:37:55 GMT References: <6914@cbmvax.UUCP> Sender: usenet@rpi.edu Organization: RPI Public Access Workstation Lab, Troy NY Lines: 35 In-reply-to: thomas@cbmvax.UUCP's message of 18 May 89 13:20:53 GMT In article <6914@cbmvax.UUCP> thomas@cbmvax.UUCP (Dave Thomas QA) writes: MEMF_PUBLIC involves memory protection if/when it is ever implemented. Memory which is MEMF_PUBLIC is accessible to multiple tasks. Non MEMF_PUBLIC memory is accessible only to your own task. Of course, currently, MEMF_PUBLIC is not meaningful; all memory is MEMF_PUBLIC. This has nothing to do with virtual memory. MEMF_PHYSICAL would specify memory which must not be swapped out, but this says nothing about accessibility to other tasks. The name MEMF_PUBLIC clearly implies a relation to memory protection (more precisely, lack thereof) yet it isn't so clearly defined. Clearly, it implies that other tasks can access the memory, (and that much the RKM clearly states) but what isn't clear is what effect, if any, such a designation should mean with regards to virtual memory. It COULD be interpreted as "any task can access the memory at any time, so it must always be in memory." Of course, if a task accesses the memory, it can be just swapped in, so that's not reason enough. However, if you consider interrupts, the argument becomes more viable. You can't expect the memory page to be swapped in if an interrupt needs to access the memory; it takes too long. And all interrupt code and data is supposed to be in MEMF_PUBLIC memory. (irregardless of the fact that the flag is currently meaningless.) This argues that MEMF_PUBLIC memory, beyond being publicly accessible, must also be locked in memory, in the event that an interrupt might access it. If you're saying that there would be an MEMF_PUBLIC flag and an MEMF_PHYSICAL flag, totally unrelated, then how do you define the case of interrupt code in or accessing virtual memory? 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.