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*.