home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.amiga.programmer
- Path: sparky!uunet!spool.mu.edu!umn.edu!uum1!kksys.com!quest!digibd!therson!swt
- From: swt@therson.affinity.mn.org (Stephen W. Thomas)
- Subject: Re: physical memory protection with MMU
- Summary: Definition of MEMF_PUBLIC
- Message-ID: <1992Nov4.195941.7028@therson.affinity.mn.org>
- Date: Wed, 4 Nov 1992 19:59:41 GMT
- References: <1992Oct26.162400@uni-paderborn.de> <paulk.25qm@terapin.com> <mwm.2fxx@contessa.palo-alto.ca.us>
- Organization: Affinity Computer Applications, Shoreview, MN
- Lines: 23
-
- In article <mwm.2fxx@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
- >
- >I don't think it was ever clearly defined what "PUBLIC" means, it's
- >pretty hard to treat it the right way.
- >
- >Is that memory that you're letting anyone access, like a public
- >message port? Or is it memory that you're going to hand to a specific
- >other task, like an I/O buffer? Or is it something else again?
-
- I believe the answer to both is yes since in both cases another task is
- accessing the memory.
-
- >Is there a place in the 2.0 RKMs that gives an explicit rule for when
- >MEMF_PUBLIC should be used?
- >
-
- On page 20 of the exec.library autodoc (page 135 of your autodoc/includes RKM)
- the definition of the MEMF_PUBLIC attribute is given.
- --
- Stephen W. Thomas UUCP: swt@therson.affinity.mn.org
- Affinity Computer Applications, Inc. VOICE: (612) 484-2905
- 4740 Hodgson Road BIX: affinity
- Shoreview, MN 55126-6042
-