home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / programm / 16003 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.6 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!iggy.GW.Vitalink.COM!cs.widener.edu!eff!sol.ctr.columbia.edu!spool.mu.edu!agate!darkstar.UCSC.EDU!cats.ucsc.edu!davids
  2. From: davids@cats.ucsc.edu (Dave Schreiber)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: physical memory prot
  5. Date: 18 Nov 1992 03:48:35 GMT
  6. Organization: University of California; Santa Cruz
  7. Lines: 44
  8. Message-ID: <1eceejINNcin@darkstar.UCSC.EDU>
  9. References: <n0e9ft@ofa123.fidonet.org>
  10. NNTP-Posting-Host: as215-ws-5.ucsc.edu
  11.  
  12.  
  13. In article <n0e9ft@ofa123.fidonet.org> Aric.Caley@ofa123.fidonet.org writes:
  14. >
  15. >Well, how about two memory lists?  Each task has its own private, protected
  16. >memory  list  (as  you  described), and then there would be "shared" memory
  17. >list.  Memory that was intended to be passed around would be allocated from
  18. >the  public memory list (or basicly, the way all memory is alloceted now!).
  19. >Now, this would require simply using the right memory flags in AllocMem() -
  20. >which  probably most applications do not.  So there's still a compatibility
  21. >problem, even though it should be easily fixed by correcting the AllocMem's
  22. >in your application and recompiling.
  23.  
  24. That's basically the same problem as we have right now:  programs don't
  25. specify shared memory properly.  It can be fixed my recompiling, but we
  26. want to avoid making that necessary if possible since it that makes it 
  27. necessary to buy upgrades, assuming the company that produced the crucial
  28. piece of software you use is still in business.
  29.  
  30. >
  31. >-so-
  32. [bunch of stuff I agree with deleted to save bandwidth]
  33.  
  34. >
  35. >Now  perhaps  I  am  completely  off  here...   but it seems like this is a
  36. >reasonable  solution.   What don't I understand, if this idea is completely
  37. >unfeasable?   Third parties have developed VM that uses a similar system to
  38. >what  I described (from what I understand, I dont have an MMU to see how it
  39. >works).
  40.  
  41. This is really something that needs to be integrated into the operating
  42. system, IMHO.  As you said (in the text I deleted :-), AmigaOS as a whole
  43. needs to be made memory-protection compliant, since every program interacts
  44. with it.  What if Intuition doesn't use MEMF_PUBLIC when allocating 
  45. memory for IDCMP messages?  This'll mean that no program that uses Intuition
  46. will be able to use memory protection, unless you write a routine that
  47. intercepts an IDCMP message and makes it public.  Doing this for every
  48. system routine that needs it could be a lot of work.  Of course, once 
  49. memory protection is implemented in Exec, the rest of the OS will be made
  50. memory-protection compliant, but for now, who knows?
  51.  
  52. >--- Maximus 2.00
  53.  
  54. -- 
  55. Dave Schreiber  "Look.  Don't touch."  davids@cats.ucsc.edu (until 6/20/93)
  56.