🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #12756

Re: MEMF_PHYSICAL?

#12756
From: Deven Corzine
Date: Fri, 19 May 1989 09:37
35 lines
2613 bytes
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]   <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.
Technical Details
Message-ID: <DEVEN.89May19053755@daniel.rpi.edu>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!rpi!rpi.edu!deven
References: <DEVEN.89May18024329@daniel.rpi.edu> <6914@cbmvax.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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: <DEVEN.89May19053755@daniel.rpi.edu>
Date: 19 May 89 09:37:55 GMT
References: <DEVEN.89May18024329@daniel.rpi.edu> <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