Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!burl!codas!killer!academ!uhnix1!sugar!peter
From: peter@sugar.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Memory Management
Message-ID: <1144@sugar.UUCP>
Date: Mon, 30-Nov-87 08:33:33 EST
Article-I.D.: sugar.1144
Posted: Mon Nov 30 08:33:33 1987
Date-Received: Fri, 4-Dec-87 02:54:26 EST
References: <8711201906.AA25134@cory.Berkeley.EDU> <1406@atkins.munsell.UUCP> <34782@sun.uucp>
Organization: Sugar Land UNIX - Houston, TX
Lines: 31
Summary: There's already a way to do this.

Doug Merritt ({ucbvax,sun}!unisoft!certes!doug) writes:
> >dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
> >>    As far as the Amiga goes, the only compatible solution is a Linear
> >>virtual address space over the entire system.
> 
> A nice idea, but unfortunately not perfectly compatible. As discussed
> here some time ago, there's still the problem of, e.g. cooperating tasks
> which have pointers into each others memory space. Message passing is
> based on shared memory on the Amiga...

Well, ignoring the paging/mapping/protection confusion...

> But wait...maybe there's a bandaid? Perhaps you could rig up a way of
> telling the system about tasks that need to share address space. Got
> any ideas about this? Any such method would be inconvenient, but might
> at least work.

WHat do you suppose the MEMF_PUBLIC bit is for? Well, I guess it must be
to tell the system that this memory should be publicly available. But all
memory is publicly available anyway, right? Ah! It's a hook for a future
memory-protected version of the operating system!

I hope all you nice people have been scrupulous about where you should and
should not be using MEMF_PUBLIC. (time to add another flag to the Aztec
linker, I guess).

Another thing to note... private memory (non MEMF_PUBLIC) should also be
mappable.
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.